n 3/31/2021 11:07 AM, Ken Brown via Cygwin wrote:
On 3/31/2021 4:24 AM, sten.kristian.ivars...@gmail.com wrote:
[snip]
Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to drop
messages or at least they are not received in the same order they
are sent
[snip]
Thanks for the test case. I can confirm the problem. I'm not familiar enough
with the current AF_UNIX implementation to debug this easily. I'd rather
spend my time on the new implementation (on the topic/af_unix branch). It
turns out that your test case fails there too, but in a completely different
way,
due to a bug in sendto for datagrams. I'll see if I can fix that bug and
then try
again.
Ken
Ok, too bad it wasn't our own code base but good that the "mystery" is verified
I finally succeed to build topic/af_unix (after finding out what version of
zlib was needed), but not with -D__WITH_AF_UNIX to CXXFLAGS though and thus I
haven’t tested it yet
Is it sufficient to add the define to the "main" Makefile or do you have to
add it to all the Makefile:s ? I guess I can find out though
I do it on the configure line, like this:
../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --prefix=...
Is topic/af_unix fairly up to date with master branch ?
Yes, I periodically cherry-pick commits from master to topic/af_unix. I'lldo
that again right now.
Either way, I'll be glad to help out testing topic/af_unix
Thanks!
I've now pushed a fix for that sendto bug, and your test case runs without error
on the topic/af_unix branch.
By the way, I think the implementation of sendto/recv for datagrams is very
inefficient when there are repeated calls to sendto as in your test case.
Nevertheless, your test case actually runs slightly faster on the topic/af_unix
branch than it does on master (when the latter succeeds, which it does about
half the time for me). So I'm not sure whether it's worth worrying about this.
Here's the issue, briefly. The communication is done via a Windows named pipe.
The receiver creates the pipe when it creates and binds its socket. It
creates only one pipe instance. The sender connects to the pipe, writes, and
closes its handle. But the pipe is not available for another sender to connect
to until the receiver reads the message, after which it disconnects the sender.
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
