RE: [EXTERNAL] Re: scp stalls on uploading in cygwin 3.5 current master.

["Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr@ncbi.nlm.nih.gov>]

> While select indicates that
> data can be written, it doesn't indicate how much data can be written.
> I. e., if select returns, and there's only buffer space for 10 bytes,
> and the send call tries to send 100 bytes, it *will* block, unless the
> socket is non-blocking and returns EAGAIN.

IIRC, if there's space for 10 bytes in the internal buffer, send(100) will return 10, whether or not the socket is blocking.
EAGAIN is only returned when nothing at all can be written to a non-blocking socket; or send() blocks (when blocking).

Anton Lavrentiev
Contractor NIH/NLM/NCBI

> -----Original Message-----
> From: Cygwin <cygwin-bounces+lavr=ncbi.nlm.nih.gov@cygwin.com> On Behalf Of Corinna
> Vinschen via Cygwin
> Sent: Friday, August 25, 2023 9:19 AM
> To: cygwin@cygwin.com
> Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
> Subject: Re: [EXTERNAL] Re: scp stalls on uploading in cygwin 3.5 current master.
>
> On Aug 25 14:23, Corinna Vinschen via Cygwin wrote:
> > On Aug 25 12:08, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > > > I don't have an answer to this problem yet.
> > > >
> > > > Can we use send(sock, "", 0) to reenable FD_WRITE, perhaps?
> > >
> > > Can't it just be assumed that the socket is _always_ writeable _unless_ the last
> send() failed?
> > > In other words, try to always send() if it did not fail before.  If it did, only
> send() after
> > > FD_WRITE was returned in the event mask.
> >
> > You're looking from the application perspective, but as the underlying
> > library we don't have the application under control.  The application
> > can rightfully expect POSIX-like behaviour from select(2), and *that*
> > means, it can expect select(2) to return a socket as non-writable if the
> > internal buffer is full, *before* it calls send:
> >
> >   while (...)
> >     {
> >       /* send as long as we can, otherwise do another job in the meantime */
> >       while (select (..., <zero timeout>))
> >       send (<blocking>);
> >       <do something else>
> >     }
>
> No, wait.
>
> I just realized that this isn't correct.  While select indicates that
> data can be written, it doesn't indicate how much data can be written.
> I. e., if select returns, and there's only buffer space for 10 bytes,
> and the send call tries to send 100 bytes, it *will* block, unless the
> socket is non-blocking and returns EAGAIN.
>
> The testcase my patch was based on called a poll/write loop on a
> socketpair without changing the socket to non-blocking before.  At the
> time I didn't even realize that it's actually not a good test, d'oh.
>
>
> Corinna
>
>
>
> --
> Problem reports:
> https://cygwin.com/problems.ht
> ml&data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Ca0231ac386e44a5dbd0008dba56e384b%7C14b77578977
> 342d58507251ca2dc2b06%7C0%7C0%7C638285665032412610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jPh5i6OE5cYkS1zZ
> 6ntr2t2c%2B%2BJgl6Gfp6YqVcypj98%3D&reserved=0
> FAQ:
> https://cygwin.com/faq/
> =05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Ca0231ac386e44a5dbd0008dba56e384b%7C14b77578977342d585
> 07251ca2dc2b06%7C0%7C0%7C638285665032412610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o4iHOc%2FbDPmql%2BxjqVl
> %2FgIM0FYW%2FN9%2Bsenjy1JqT9oE%3D&reserved=0
> Documentation:
> https://cygwin.com/docs.html
> ata=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Ca0231ac386e44a5dbd0008dba56e384b%7C14b77578977342d
> 58507251ca2dc2b06%7C0%7C0%7C638285665032412610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i0y2q1tMqjh78EeJhBOh
> swPgYENictSU7V2XnMEFZ5k%3D&reserved=0
> Unsubscribe info:
> https://cygwin.com/ml/#uns
> ubscribe-
> simple&data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Ca0231ac386e44a5dbd0008dba56e384b%7C14b7757
> 8977342d58507251ca2dc2b06%7C0%7C0%7C638285665032412610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bT4vlE52NW83
> P4xFNOeu2wTSWq9k1WdZ573j03JKHHA%3D&reserved=0
> CAUTION: This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and are confident the content is safe.