On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter. The problem is
that hamlib recovers from the timeout but when it's done WSJT-X has
already timed out and shuts down rigctld. And it also looks like
WSJT-X starts another connection before closing the first one which
then gives the invalid configuration error....maybe that's where a
synchronous close would work better....but it looks like the idea
there was a client just tells rigctld "I'm done" and that's a 1-way
conversation. If we make it synchronous then the client has to stay
around to take the answer or else we start hitting timeouts in
rigctld. I'm a bit reluctant to make it synchronous as I don't know
what all the client programs are expecting.
And if we make it synchronous and rigctld goes away then the client
will be timing out trying to close it.
All timeouts are arbitrary but have to be based on what the hardware
can do. .
Making the timeout = pollrate is arbitrary too. If you made the
polling 10ms everything would time out like crazy.
We've got a lot of rigs that just aren't very fast on CAT and 1 second
is too short.
The timeouts aren't hit very often and nobody will even notice it in
WSJT-X if there's a 3-second timeout that almost never gets triggered.
What they do notice is WSJT-X timing out too quickly. And the more
data we ask from the rigs the more likely we are to hit the 1 second
timeout.
Mike
Hi Mike,
if WSJT-X is overlapping rig_open/rig_close calls then it should be
doing it on a separate RIG handle, that should not cause a problem.
I thought the Hamlib API was synchronous, why is the rig_close call
being treated differently, that's very confusing to me.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
