And please give consideration to lengthening the timeout to 3 seconds....we'll
get rid of a lot of complaints about timeouts.
Mike
On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
Hi Mike,
OK, hold off from any Hamlib changes to rig_close for now. I will do some
tests when I get some time and work out if WSJT-X is really calling rig_open
twice on the same RIG handle without an intervening rig_close. I'll get back to
you.
73
Bill
G4WJS.
On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
I have no idea why it's treated differently....been that way since day#1.
I could add a flag to the RIG structure for "close_is_sync" that a client
could set if it wants a synchronous close.
That way we wouldn't break any other apps not expecting it.
Mike
On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
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
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
