X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 75483388A404
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1617871054;
	bh=R1yjCDNnsAW+bJhoaZzq161pqIJUlI4sltQsHP4uOFQ=;
	h=To:References:In-Reply-To:Subject:Date:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=WNvxUfz+vejgWIpwEFjYnV0gKE04IlztX24tXKrxWE1nMFVwJbOgFlLayRv7qyw+C
	wtohU3qB5H3i2jCFmSQWlp3p09V563kFEaP6JvsVb8PrvgQlajFKRzr+W0vaeWXcck
	6kRevS9TitxOwO9ooxbiExR6bE1oO5QOUvHpEjbA=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 4BE613854804
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-language:thread-index;
	bh=P1JJDPYqH6A5YgS7F8QeLkpF+EjD6g3GcjufZ4MUOz4=;
	b=XUnSKSIEXbRphAihHrLSULGCi8iz1vMVth3JcJgFx7OuK8IX30fPfQXIDOyO8/0sEs
	dPQOL269RCbKV9gjzdunCMgxgG0orWFc0D73lCpfLEKUILtvPnVQykg3uZnWyWckQDbY
	HriaOzfnxPOBZNFNX85g5JPHVxm9E9Gfj4n7IXQa2Zjs4iCwTG/gqeVhQuLEz6et4U4s
	4F2bvK2auwGQ1ftQRUZpyDhI0fSJDqGOkH7pLxZLR3dnPS8H5z1iyKsbkqPeQy51XV1m
	eHTwTMCuXTP7bagYppo6PFOsFjH6I8HqiL01V0IatucSsMoK8/giAcYm9D2pweTGWWtl
	v7oA==
X-Gm-Message-State:	AOAM53072t8wwvfmdecK8krQjT8QMIrHKV+YSC784f8NeaUrEfo9WJHF
	hB6Fq8oqbYEmOhKS2EwowDDcK2Di10Ww/w==
X-Google-Smtp-Source:	ABdhPJzPYMK7cDb2l5xaga7JtB2wRXQrNuQ3CIwbHyHcTpu1fcd+nFzUEIbRmCPa5L8BYI16SIrx1A==
X-Received:	by 2002:a2e:b5a5:: with SMTP id f5mr4987661ljn.336.1617871049028;
	Thu, 08 Apr 2021 01:37:29 -0700 (PDT)
To:	"'Ken Brown'" <kbrown AT cornell DOT edu>, <cygwin AT cygwin DOT com>
References:	<04cc01d71ffa$7d1e6cf0$775b46d0$@gmail.com>
	<YFo/fFC2bITvnVGr AT xps13> <00d901d7208e$97c05c50$c74114f0$@gmail.com>
	<860668bf-8cf9-0969-6a01-7fbf8b782db1 AT cornell DOT edu>
	<000901d72607$55dc5a90$01950fb0$@gmail.com>
	<3346cd1c-b93f-83c4-ff26-553ac95ec692 AT cornell DOT edu>
	<7c21a430-9609-7fd4-1a02-8b7c1978d2f8 AT cornell DOT edu>
	<001901d72af4$4009cd50$c01d67f0$@gmail.com>
	<134074c1-4c0b-0842-b88b-536a1ed4aefe AT cornell DOT edu>
In-Reply-To:	<134074c1-4c0b-0842-b88b-536a1ed4aefe@cornell.edu>
Subject:	RE: AF_UNIX/SOCK_DGRAM is dropping messages
Date:	Thu, 8 Apr 2021 10:37:29 +0200
Message-ID:	<002101d72c52$695ea630$3c1bf290$@gmail.com>
MIME-Version:	1.0
X-Mailer:	Microsoft Outlook 16.0
Thread-Index:	AQIPffBCgY7dkx32YYBd4buxXBOzegICwCl2At957CQCAh4QbgK/qZQ0Aiflzi4DDsW9ugMOPnyiAg8iLcGpmeMO0A==
X-Spam-Status:	No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Kristian Ivarsson via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	sten DOT kristian DOT ivarsson AT gmail DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

This is a multipart message in MIME format.

------=_NextPart_000_0022_01D72C63.2CE83980
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> >>>>>>>> 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=E2=80=99t 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=3D"-g -O0 -D__WITH_AF_UNIX" --
> prefix=3D...
> >>>
> >>>> 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.
> >
> > It seems like the test-case do work now with topic/af_unix in =
blocking
> > mode, but when using non-blocking (with MSG_DONTWAIT) there are
> some
> > issues I think
> >
> > 1. When the queue is empty with non-blocking recv(), errno is set to
> > EPIPE but I think it should be EAGAIN (or maybe the pipe is getting
> > broken for real of some reason ?)
> >
> > 2. When using non-blocking recv() and no message is written at all, =
it
> > seems like recv() blocks forever
> >
> > 3. Using non-blocking recv() where the "client" does send less than
> > "count" messages, sometimes recv() blocks forever (as well)
> >
> >
> > My na=C3=AFve analysis of this is that for the first issue (if any) =
the
> > wrong errno is set and for the second issue it blocks if no sendto()
> > is done after the first recv(), i.e. nothing kicks the "reader =
thread"
> > in the butt to realise the queue is empty. It is not super clear
> > though what POSIX says about creating blocking descriptors and then
> > using non-blocking-flags with recv(), but this works in Linux any =
way
>=20
> The explanation is actually much simpler.  In the recv code where a =
bound
> datagram socket waits for a remote socket to connect to the pipe, I =
simply
> forget to handle MSG_DONTWAIT.  I've pushed a fix.  Please retest.

I tested it and now it seems like we get EAGAIN when there's no msg on =
the queue, but it seems like the client is blocked as well and that it =
cannot write any more messages until it is consumed by the server, so =
the af_unix.cpp test-client end prematurely

If using sendto() with MSG_DONTWAIT as well, that is getting a EAGAIN, =
but the socket in it self is not a non-blocking socket, it is just the =
recv() that is done in a non-blocking fashion

As I said earlier, it's a bit fuzzy (or at least for me) what POSIX mean =
by non/blocking descriptors combined with non/blocking operations, but =
as far as I understand, it should be possible to use blocking =
sendto()and messages should be written (as long as some buffer is not =
filled) at the same time someone is doing non-blocking recv()

What is your take on this ?

> I should add that in all my work so far on the topic/af_unix branch, =
I've
> thought mainly about stream sockets.  So there may still be things =
remaining
> to be implemented for the datagram case.
>=20
> Ken

------=_NextPart_000_0022_01D72C63.2CE83980
Content-Type: text/plain;
	name="af_unix.cpp"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="af_unix.cpp"

#include <sys/socket.h>
#include <sys/un.h>

#undef AF_UNIX
#define AF_UNIX 31

#include <unistd.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <thread>
#include <chrono>


// $ g++ --std=3Dgnu++17 af_unix.cpp

const char* const path =3D "address";
const int count =3D 10;
const int size =3D BUFSIZ * 1;

int client()
{
    const int fd =3D socket( AF_UNIX, SOCK_DGRAM, 0);

    if( fd =3D=3D -1)
    {
        perror( "socket error");
        return -1;
    }

    struct sockaddr_un address{};

    strcpy( address.sun_path, path);
    address.sun_family =3D AF_UNIX;

    char buffer[size] =3D {};

    for( int idx =3D 0; idx < count; ++idx)
    {
        memcpy( buffer, &idx, sizeof idx);

        fprintf( stdout, "client idx: %d\n", idx);
   =20
        const ssize_t result =3D sendto( fd, buffer, size, 0, (struct =
sockaddr*)&address, sizeof address);

        // Assume the whole chunk can be sent
        if( result !=3D size)
        {
            perror( "sendto error");
            return -1;
        }
    }

    close( fd);
    return 0;
}

int server()
{
    const int fd =3D socket( AF_UNIX, SOCK_DGRAM, 0);

    if( fd =3D=3D -1)
    {
        perror( "socket error");
        return -1;
    }

    struct sockaddr_un address{};

    strcpy( address.sun_path, path);
    address.sun_family =3D AF_UNIX;

    const int result =3D bind( fd, (struct sockaddr*)&address, sizeof =
address);

    if( result =3D=3D -1)
    {
        perror( "bind error");
        return -1;
    }

    return fd;
}

int main( int argc, char* argv[])
{
    const int fd =3D server( );

    if( fd !=3D -1)
    {
        fprintf( stdout, "%d\tnumber of packages\n", count);
        fprintf( stdout, "%d\tbytes per package\n", size);

        std::thread{ [&](){client( );}}.detach();

        std::this_thread::sleep_for( std::chrono::microseconds( 250));
   =20
        char buffer[size] =3D {};

        for( int idx =3D 0; idx < count; ++idx)
        {
            fprintf( stdout, "server idx: %d\n", idx);

            const ssize_t result =3D recv( fd, buffer, size, =
MSG_DONTWAIT);

            // Assume the whole chunk can be read
            if( result !=3D size)
            {
                perror("recv error");
                unlink( path);
                return -1;
            }

            int index =3D 0;
            memcpy( &index, buffer, sizeof idx);

            if( index !=3D idx)
            {
                fprintf( stderr, "expected %d but got %d\n", idx, =
index);
                unlink( path);
                return -1;
            }
        }

        close( fd);
        unlink( path);
    }

    return 0;
}
------=_NextPart_000_0022_01D72C63.2CE83980
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
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

------=_NextPart_000_0022_01D72C63.2CE83980--

- Raw text -