SamY wrote: > As per the update to my previous post regarding this issue, I have > isolated the problem to a bit of non-standard behavior affecting *LMS > running on Windows only*.
An update on this. I knew the situation felt familiar and, sure enough, it's the same problem I ran into when porting my distributed TCP client/server apps from Unix to Windows some 25 years ago. Initial coding and testing was done on Unix platforms and everything ran smoothly. However, the same C code, compiled under Visual C++ on Windows, would result in all sorts of strange problems on the server side. I finally tracked it down to the fact that there was no straightforward way to implement non-blocking socket communication in Windows. It's a simple matter of setting a flag in the socket object on Unix. However, even though the flag exists in Windows and can be set, it has no effect. Apparently, even 25 years later, the only real way to do this in Windows is to poll the socket for input before issuing a read(). Otherwise, the entire server will be blocked until input is available. What I can't believe is that Microsoft still hasn't fixed this, given all the time they've had to do it. The bottom line is that, since the plugin subroutine that makes use of the "offending" code is non-essential and was just added for the sake of efficiency, I am removing it in the next release for both Windows and Unix. In the meantime, Windows users should replace the installed copy of DenonAvpComms.pm in the plugin directory with the one attached to my previous post. No action is required for those running LMS on a non-Windows platform. Sam ------------------------------------------------------------------------ SamY's Profile: http://forums.slimdevices.com/member.php?userid=63495 View this thread: http://forums.slimdevices.com/showthread.php?t=60114 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
