On Wed, 2004-04-28 at 18:50, David Thompson wrote: > I've run into a situation that I'm trying to solve for Windows. It > involves communication between the UI and the exec. I have got to a > point where the UI is trying to UxSend to the open socket and the > exec is trying to WriteSFILE to the same socket. UxSend is set up to > do a select() first to see if the socket is available, but since > WriteSFILE is flooding the socket--it isn't. UxSend then errors out > and exits out hard. So anybody got a solution? If I use > DXMessageOnSocket to check it, it says there is data still on it--but > then how should I go about processing it? UxSend doesn't have access > to the PacketIF construct in order to force it to continue processing > input. > > Greg, Martin? Any ideas? > It's dining philosophers. The fork is the buffer space. Picking up the fork is dxui calling fwrite (or fputs or fflush) to send data to dxexec. If the buffer is full, dxui is stuck. ...i.e. it can't put it's fork back down. ...and then dxexec picks up its fork. Nothing is gonna change that.
It's not hard to interleave reading and writing inside PacketIF. I've done it and it allows me to run many samples with DX_SOCKET_BUFSIZE set to 512. Eventually, it will hang with such a small buffer. I can run for a long time with it set to 8K. Neither of those works with the released product although it is luck-of-the-draw. The remaining problem is that there are calls that write information to dxexec in many places inside dxui, not just in PacketIF. (You can find them by grepping for _UNIX_SOCKET.) Each place has to be dealt with. For example, if I use a really small DX_SOCKET_BUFSIZE then eventually I'll hang trying to send the Image macro. So, perhaps if I handle all the cases of socket writes and not just the ones in PacketIF, the deadlock will happen so rarely that it won't bother people anymore. Martin
