On 09/09/2014 15:28, Michael Black wrote: Hi Mike, > Yep...same context# on all 3. OK, so that's no the problem since HRD logbook and DM780 cooperate. > > Here's what I think now that might explain why sometimes it works and > sometimes not. > It does appear that HRD spawns a thread for each client. But is the > underlying select giving first-come-first-serve priority? It sure looks > like it. > So when you start HRD, then Logbook, then WSJT-X, Logbook gets priority as > the first socket in the select. select() doesn't work like that, it is designed to be used with a non-threaded handler (threads can be used to hive off expensive or blocking requests but select() gives you a clean way of doing asynchronous socket handling without threads). You pass an array of file descriptors (sockets) that you are interested in and it marks all that are ready to read (or write or have a pending error). So it is up to the application to choose which of the ready descriptors to act on.
If you are right (and it does look like that) the algorithm in the HRD IP server is always looking at the lowest number ready descriptor and servicing that first. By the time it has done that another command is incoming on that socket. It probably then makes the mistake of calling select() again whereas it should continue with the original ready list servicing all the ready sockets from the first select() before doing a fresh select. That way no client will be starved of service. Alternatively with a thread per client (poor strategy anyway since threads are expensive) each server thread should only do a select() on the descriptor(s) it is responsible for. The problem then is starvation can happen if that thread is CPU intensive and keeps getting new client requests. Just guessing and not about to start reverse engineering HRD server internals, let's hope they think it's worth investigating. <snip> 73 Bill G4WJS. ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
