Re: [Hamlib-developer] serial ports and hamlib

[Stephane F. <f8...@fr...>]

On Tue, Feb 25, 2003 at 11:13:53AM +0100, Alexandru Csete wrote:
> Yes, exactly. I was thinking of solving this problem by having ONLY ONE
> "main loop" interacting with Hamlib continuously, waiting politely for
> slow connections and timeouts, and storing the read/set values in shared
> memory which can be accessed by the rest of the application. This will
> probably introduce some delay between the set and get values, but it's
> still better than having a blocked GUI.

kind of poll in main loop?

> As long as we have a direct link between Hamlib and a GUI, there will
> always be the possibility of this to-way struggle: An aggressive GUI
> might easily overload Hamlib, which in turn will block the GUI. 
> If we want to avoid such things in the long run, we should work toward
> the client/server scheme, where we have a well designed server daemon
> talking to Hamlib in one end, and accepting requests from clients
> through pipes and/or sockets in the other end. The rpc.rigd may already
> fulfill some of this.

nope, the RPC backend won't be better either. The problem here is
latency of synchronous protocols in general (command ... delay ... response).

One solution is to make Hamlib asynchronous wrt to protocol handling,
using either signal handler or poll in a main loop.
This way you don't block waiting for the response. Event driven application
is a nice concept, but not so easy to implement because the need of a state
machine, and your main loop is nothing else but a degenerated "scheduler".

The other solution, more common, is to make the application
multi-threaded (or at least multi-programmed). This way, the GUI main
loop is not blocked by the delayed reponse. However, the developer has to
pay attention to proper locking within shared data structures...

Now, I cannot see Hamlib to be asynchronous wrt transaction type
commands in the forseable future...

Comments?


Cheers,
Stephane