On 9/20/2022 1:20 PM, Enrico Forestieri wrote:
On Tue, Sep 20, 2022 at 06:18:54PM -0700, Ken Brown wrote:
On 9/20/2022 2:54 AM, Enrico Forestieri wrote:
I compared the behavior of read() and select() on 3 different platforms.
My conclusion is that, actually, read() behaves the same on all
On Tue, Sep 20, 2022 at 06:18:54PM -0700, Ken Brown wrote:
>
> On 9/20/2022 2:54 AM, Enrico Forestieri wrote:
> >
> > I compared the behavior of read() and select() on 3 different platforms.
> > My conclusion is that, actually, read() behaves the same on all of them,
> > whereas cygwin differs
On 9/20/2022 2:54 AM, Enrico Forestieri wrote:
On Mon, Sep 19, 2022 at 07:54:11PM -0400, Ken Brown wrote:
Then I guess I'm wrong. I'm really puzzled, because it seems that none of these
platforms agree with POSIX, which says the following in its 'read'
documentation:
When attempting to
On Mon, Sep 19, 2022 at 07:54:11PM -0400, Ken Brown wrote:
>
> On 9/19/2022 6:05 PM, Enrico Forestieri wrote:
> > Ken Brown wrote:
> > >
> > > I did an internet search on this issue and found the following, which
> > > describes the
> > >
> > > situation we're discussing:
> > >
> > > https://s
> It seems that there's an exception: If no process has ever had the FIFO open
> for
> writing since it was opened for reading, then the FIFO is not considered to be
> at end-of-file.
IMO, when a virgin FIFO is read with a blocking read (of just one byte), it
will block -- it will not return 0.
On 9/19/2022 6:05 PM, Enrico Forestieri wrote:
Ken Brown wrote:
> I did an internet search on this issue and found the following, which
describes the
> situation we're discussing:
https://stackoverflow.com/questions/14594508/fifo-pipe-is-always-readable-in-select
> According to that po
Ken Brown wrote:
> I did an internet search on this issue and found the following, which
describes the
> situation we're discussing:
https://stackoverflow.com/questions/14594508/fifo-pipe-is-always-readable-in-select
> According to that post, select on Linux will wait for a writer the
fi
On 9/19/2022 5:25 PM, Ken Brown wrote:
You're probably not calling select to check for read ready on
non-blocking FIFOs that have no writers.
Exactly what I was thinking (while on the bus).
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq
On 9/19/2022 3:53 PM, Norton Allen wrote:
On 9/19/2022 3:50 PM, Norton Allen wrote:
On 9/19/2022 3:15 PM, Ken Brown wrote:
On 9/18/2022 5:45 PM, Enrico Forestieri wrote:
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/p
On 9/19/2022 3:50 PM, Norton Allen wrote:
On 9/19/2022 3:15 PM, Ken Brown wrote:
On 9/18/2022 5:45 PM, Enrico Forestieri wrote:
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs
On 9/19/2022 3:15 PM, Ken Brown wrote:
On 9/18/2022 5:45 PM, Enrico Forestieri wrote:
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe
On 9/18/2022 5:45 PM, Enrico Forestieri wrote:
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out.
Compiling this source on linux and
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out.
Compiling this source on linux and launching it produces on the terminal
1) Openin
13 matches
Mail list logo
