Re: [Hamlib-developer] serial ports and hamlib

[Alexandru C. <al...@ph...>]

On Mon, 2003-02-24 at 21:50, Stephane Fillod wrote:
> Now, let's do the math.
> The communication is set to 1200 bauds, which is 120 byte/s using 8N1.
> This allows 40 bytes per exange, since xlog/tlf poll ~3 times a sec.
> Note: the link is full duplex, but most of the time the protocol is
> half duplex.
> This is still okay, but now, what if the rig is a bit slow at answering?
> It may block the GUI and its event-handling loop.

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.

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.

Alex, OZ9AEC