Hamlib 3 API

From hamlib

Hamlib 3 API ideas

In June 2011 there was some some discussion about possible improvements to the current Hamlib 1.2 API which has been stable for some time. The following is a list of those ideas gleaned from the mailing list list along with a few others that may be considered.

Thread Safety

This is an ongoing issue and with greater use of rigctld and rotctld by multiple applications is probably an area that deserves a lot of discussion and some solutions. Stephane posted the following on 20 Jan 2011:

> > Do you know anything about the thread-safety of hamlib? I currently
> > have the hamlib calls in a separate thread so the GUI thread can
> > update as needed. That works fine with one radio. But I am not sure
> > when I use two radios whether those calls can be in separate threads
> > (easier to program when the poll time is different for the two
> > radios), or if all hamlib calls need to come from one thread?
> 
> So far as I know, Hamlib is not thread safe.  I think that keeping it in
> its own thread is the wise choice.  You might want to ask Stephane,

Indeed, Hamlib is not thread safe within one backend, because we didn't want
to force a lib pthread dependancy on users. Two threads cannot access the
same rig without appropriate locking (or puting the calls in a dedicated thread).
by the end-user program.

However, Hamlib and its backends is multi-rig safe and should be reentrant,
i.e. you can instantiate more than once the same backend or different backends
in the same program. Running multiple rigs in their own thread should
work without locking, with the limitation that the frontend
initialization (rig_init()/rig_cleanup()/..) are not thread-safe.
Maybe this topic needs more investigation and be properly documented.

Indeed this does warrant more thought and discussion.

As I (N0NB) understand it, Hamlib is not designed or implemented in such a way as to allow multiple user applications to connect to the same device via the C API. I have done it and it seems that eventually one or more of the apps will get out of sync with the device. This topic is ripe for experimentation.

rigctld/rotctld cache or ???

In a thread from 10 Oct 2011 I (N0NB) posted thoughts for a performance enhancement to rigctld/roctld to handle multiple commands before the hardware device returned a reply using a cache. Charles AA1VS suggested that a mutex might be a better way to go. In a series of followups more discussion came back to the thread safety of Hamlib.

This needs more exploration.