> >> [snip] > >> > >>>> I tried SOCK_STREAM (and SOCK_SEQPACKET I think) for CYGWIN 3.2.0 > >>>> but that didn't work at all > >>>> > >>>> As far as I understand, both all types on pretty much all > >>>> implementations preserves message ordering though > >>>> > >>>> I haven't tried SOCK_STREAM and/or SOCK_SEQPACKET with the > >>> topic/af_unix-branch. Is that worth a try ? > >>> > >>> SOCK_STREAM is definitely worth a try. The implementation of that > >>> should be much more reliable than the implementation of SOCK_DGRAM > >>> at the moment. We don't implement SOCK_SEQPACKET. > >> > >> It might be a complete rewrite of our semantics though, because it's > >> connection based and allows just one writer on each "channel" and > >> messages > >> (chunks) cannot be handled "atomically" > > > > In that case, let's try to get the DGRAM case to work. > > I decided to (finally) dig into the AF_UNIX implementation on the master > branch and try to understand why DGRAM sockets are unreliable. I think the > answer is simply that Cygwin implements AF_UNIX sockets using Windows > AF_INET sockets, and DGRAM sockets in this setting are documented to be > unreliable. It appears that if too much is written without anything being > read, > the Windows WSASendTo function simply drops messages without giving any > error.
Yeah, that was my amateur analysis as well a while ago > Unfortunately, switching to native Windows AF_UNIX sockets wouldn't help, > because they don't support DGRAM sockets. That's a bummer ☹ > I'm going to follow up on cygwin-developers. Great, I'll read about it there Keep up the good work Best regards, Kristian > Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
