Sv: Sv: Problems with native Unix domain sockets on Win 10/2019

[<sten.kristian.ivarsson@gmail.com>]

[Snip]
> >> Hi all
> >>
> >> Does anyone know the status of these fixes ?
> >>
> >> I saw an announcement for cygwin-3.2.0-0.1 that seemed to contain
> >> some AF_UNIX-related fixes but I fail to find out where that
> >> distribution exists (if it is supposed to be publicly accessible?),
> >> but I tried out the
> >> 2021-03-01 snapshot and perhaps they are similar ?
> 
> You can install cygwin-3.2.0-0.1 in the usual way, through Cygwin's setup
> program.  Since it's a test release, you'll have to explicitly select that
> release; setup won't just offer it to you.

Ahh thanks, it took a while before I noticed that Text-checkbox ;-)

See more below

> >> We bumped into some AF_UNIX-related issues when trying the 2021-03-01
> >> -snapshot though. It might be some flaws in our code base but the
> >> same code works in quite a few Linux-distros
> >>
> >> We're more than willing to help out with testing this and/or trying
> >> to narrow down any possible cygwin issues, but first we'd be glad if
> >> someone could give us some kind of status report of this (so no one
> >> is doing any unnecessary work)
> >>
> >>
> >> Best regards,
> >> Kristian
> >>
> >> p.s.
> >>     I tried to build the topic/af_unix -branch according to the FAQ,
> >> but there was some issues
> 
> I'm still in the middle of some things on that branch, and I haven't had
> much time to work on it recently.  I hope to get back to it very soon.  In
> order to build it, you need to add -D__WITH_AF_UNIX to CXXFLAGS. 

Is this when building newlib-cygwin ? I discovered now that I had wrong
MinGW installed and apparently other things are missing as well

See more below

> In order to test it, you need
> 
> #undef AF_UNIX
> #define AF_UNIX 31
> 
> after including <sys/socket.h>
> 
> Ken


The issues we're experiencing is that messages are lost during heavy load.
We essentially do have one thread writing a bunch of messages with a fixed
buffer chunk size and one thread consuming and sometimes messages disappear
or at least end up in the wrong order. When playing around with the size of
the buffer (we sometimes get -1 but no errno) from write and/or receive

Another observation is that for smaller number of, it is faster than named
pipes but the more messages that are written/consumed the performance
derogates a in the end throughput is getting exponentially slower

Hopefully, this is a defect in our code base, but I will try to narrow it
down with and try to reproduce the behaviour and I will then possibly make
another issue at this mailing list

Keep up the good work

Best regards,
Kristian