On Mon, 28 Aug 2023 14:07:44 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote:
> > For message-oriented sockets, a zero-length transport datagram is sent.
>
> And how is that acceptable? This will interject a message into some
> application protocol,
> which may not be expected at the
> For message-oriented sockets, a zero-length transport datagram is sent.
And how is that acceptable? This will interject a message into some
application protocol,
which may not be expected at the application level.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports:
On Mon, 28 Aug 2023 13:37:11 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote:
> > You seems to reffer Linux man, however, this patch calls
>
> I was referring to a known behavior. Your patch gets to call send(s,"",0),
> which is technically a write call, and which in this case, falls into an
> You seems to reffer Linux man, however, this patch calls
I was referring to a known behavior. Your patch gets to call send(s,"",0),
which is technically a write call, and which in this case, falls into an
undefined
domain for its argument, and hence, may be expected to change without notice.
On Sat, 26 Aug 2023 14:08:34 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote:
> IMO you're triggering an undefined (or not well-defined) behavior, because of
> the murky status
> of the byte count of 0. It may work now, but it may not work in the future...
>
> RETURN VALUE
>On
On Aug 26 14:15, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > This thread is not about send() blocking or returning EAGAIN. This
> > is about the behaviour of select(2) and poll(2).
>
> I was merely commenting on your note that if select() returned a socket as
> writable, and
> This thread is not about send() blocking or returning EAGAIN. This
> is about the behaviour of select(2) and poll(2).
I was merely commenting on your note that if select() returned a socket as
writable, and send() writes more than internally allowed, then send() would
block.
It wouldn't!
> > Can we use send(sock, "", 0) to reenable FD_WRITE, perhaps?
>
> Your idea seems to work. The following patch looks to solve the issue.
> Is it supposed to be any side effect()?
IMO you're triggering an undefined (or not well-defined) behavior, because of
the murky status
of the byte count
On Aug 25 23:27, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > 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
> -Original Message-
> From: Cygwin On Behalf Of
> Corinna
> Vinschen via Cygwin
> Sent: Friday, August 25, 2023 9:19 AM
> To: cygwin@cygwin.com
> Cc: Corinna Vinschen
> 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
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
> 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()
13 matches
Mail list logo
