Re: cygwin-1.5.16-1: FIFOs broken
Christopher Faylor cygwin.com> writes: > > On Mon, May 02, 2005 at 02:36:12AM -0400, Lev S Bishop wrote: > >On linux, both keep waiting for someone to write to the fifo. On > >cygwin, when the second cat tries to listen on the fifo, they both > >exit. I don't know how fifos are supposed to work, but I'm guessing > >cygwin gets it wrong here. > > Yes, this is one of the reasons that I can't say "fifos work fine" in > cygwin. Why not look at how POSIX defines FIFOs to work. XBD 3.162 defines a FIFO as a special file whose behavior is further specified in open(2), read(2), write(2), and lseek(2). open(2) states that when opening a FIFO, O_RDWR is undefined (you can only portably open a FIFO for just reading or just writing, so bash's `echo <>fifo' evokes undefined behavior). Then, if O_NONBLOCK is set, O_RDONLY succeeds but O_WRONLY fails unless there is a previously open reader; if clear, O_RDONLY blocks until there is a writer and O_WRONLY blocks until there is a reader. lseek(2) states that seeking on a FIFO fails with ESPIPE. write(2) states that there are atomicity requirements on writes less than PIPE_BUF bytes. It also states whether the write will succeed, fail with EPIPE, or with EAGAIN, based on blocking mode and available space in the pipe to the reader. But in all cases, it will never return 0 (pipes always make progress, or in non-blocking mode return an error immediately). read(2) states that a reader succeeds with 0 for end-of-file when there is no writer, fails immediately with EAGAIN if there is a writer but no data available in non-blocking mode, or blocks until the writer provides data (or the writer closes) in blocking mode. When using redirections from the shell command line, you are opening the pipe in blocking mode. So it shouldn't matter whether a writing process or a reading process is spawned first (the first end blocks until the second end has opened its descriptor), but neither process should complete until the last writing process closes its file descriptor (perhaps by exiting) to give the reader(s) an end-of-file indication, or the last reader closes its file descriptor to give the writer(s) an EPIPE. The trick of `echo 99 >fifo&' ensures that there is a writer for a very long time, so that a reader never gets EOF. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
On Mon, May 02, 2005 at 10:30:40AM -0400, Igor Pechtchanski wrote: >On Sun, 1 May 2005, Christopher Faylor wrote: >> If you want to more-or-less duplicate the behavior of 1.5.15 you can do >> something like this: >> >> (echo 9&; echo YOUR TEXT HERE) > /tmp/FIFO > >This is pretty obvious from the context and the following paragraph, but >just to clarify for the archives: the above should be > >(sleep 9&; echo YOUR TEXT HERE) > /tmp/FIFO Actually, it should be: (sleep 9& echo YOUR TEXT HERE) > /tmp/FIFO i.e., no semicolon. But, then, 'cat <>' is better. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
On Mon, May 02, 2005 at 02:36:12AM -0400, Lev S Bishop wrote: >On linux, both keep waiting for someone to write to the fifo. On >cygwin, when the second cat tries to listen on the fifo, they both >exit. I don't know how fifos are supposed to work, but I'm guessing >cygwin gets it wrong here. Yes, this is one of the reasons that I can't say "fifos work fine" in cygwin. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
On Sun, 1 May 2005, Jerry D. Hedden wrote: > However, that said, the above WJFFM. In fact, it works more like > linux in 1.5.16 than it does on 1.5.15, i.e., the cat command exits > after printing "YOUR TEXT HERE" whereas it continues to block in > 1.5.15. > > >> I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior > >> you mentioned with the 'cat' exiting after it reads text. However, > >> this is a bad thing. It means that the FIFO is being set EOF after > >> there is no more data. I tried my client-server app with the > >> snapshot cygwin1.dll, and it failed because of this. > >> > >> It seems to me that the behavior of FIFOs under 1.5.15 was correct, > >> and that under both 1.5.16 and the snapshot, FIFOs are now broken. > > > FWIW, I just tested your example under Solaris 8 and it works just > > like Christopher describes. > > Okay. I have seen the error of my ways. I'm going to rewrite my app to use > UPD instead. Try running your test case using "cat <>/tmp/FIFO". If it works, look at the bash sources to see how the <> redirection is implemented, and use that in your app. It should be less effort than rewriting all of the communication code (unless your app is very small). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
On Sun, 1 May 2005, Christopher Faylor wrote: > On Sat, Apr 30, 2005 at 09:52:28PM -0500, Ren? Berber wrote: > >Jerry D. Hedden wrote: > >[snip] > >>> However, that said, the above WJFFM. In fact, it works more like linux > >>> in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after > >>> printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. > >> > >> I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior you > >> mentioned with the 'cat' exiting after it reads text. However, this is > >> a bad thing. It means that the FIFO is being set EOF after there is no > >> more data. I tried my client-server app with the snapshot cygwin1.dll, > >> and it failed because of this. > >> > >> It seems to me that the behavior of FIFOs under 1.5.15 was correct, and > >> that under both 1.5.16 and the snapshot, FIFOs are now broken. > > > >FWIW, I just tested your example under Solaris 8 and it works just like > >Christopher describes. > > I think the previous <1.5.15 implementation of fifos represented my > ever-evolving understanding of how they are supposed to work. Either > that or it was just a bug. > > (FWIW, I just tried the example on another machine and still see success > with 1.5.16.) > > If you want to more-or-less duplicate the behavior of 1.5.15 you can do > something like this: > > (echo 9&; echo YOUR TEXT HERE) > /tmp/FIFO This is pretty obvious from the context and the following paragraph, but just to clarify for the archives: the above should be (sleep 9&; echo YOUR TEXT HERE) > /tmp/FIFO > As long as there is something sitting around which has the fifo open, > the cat process will not terminate. Of course, there will be a long > running sleep process sitting around in the above example and that > may not be desirable. So, there may be a more elegant way to do this. > > I thought that maybe something like: > > cat < FIFO 42>FIFO > > might work since that would cause cat to keep FIFO open for input and > output but that just hangs on both cygwin and linux. Interestingly enough, cat <>/tmp/FIFO seems to work for me on RH7.3 (kernel 2.4.18-3, bash 2.05a). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
cgf wrote: > I thought that maybe something like: > > cat < FIFO 42>FIFO > > might work since that would cause cat to keep FIFO open for input and > output but that just hangs on both cygwin and linux. Probably the right thing to do is: in one shell: $ cat < fifo in the other shell: $ exec 6>fff $ echo hello >&6 $ echo more >&6 $ exec 6>&- (or something similar). Or a more similar approach to your one also seems to work: $ cat <> fifo One thing that is different on cygwin to linux, is if there are multiple readers of a fifo. shell 1: $ cat fifo shell 2: $ cat fifo On linux, both keep waiting for someone to write to the fifo. On cygwin, when the second cat tries to listen on the fifo, they both exit. I don't know how fifos are supposed to work, but I'm guessing cygwin gets it wrong here. Lev -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
However, that said, the above WJFFM. In fact, it works more like linux in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. >> I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior >> you mentioned with the 'cat' exiting after it reads text. However, >> this is a bad thing. It means that the FIFO is being set EOF after >> there is no more data. I tried my client-server app with the >> snapshot cygwin1.dll, and it failed because of this. >> >> It seems to me that the behavior of FIFOs under 1.5.15 was correct, >> and that under both 1.5.16 and the snapshot, FIFOs are now broken. > FWIW, I just tested your example under Solaris 8 and it works just > like Christopher describes. Okay. I have seen the error of my ways. I'm going to rewrite my app to use UPD instead. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
On Sat, Apr 30, 2005 at 09:52:28PM -0500, Ren? Berber wrote: >Jerry D. Hedden wrote: >[snip] >>> However, that said, the above WJFFM. In fact, it works more like linux >>> in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after >>> printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. >> >> >> I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior you >> mentioned with the 'cat' exiting after it reads text. However, this is >> a bad thing. It means that the FIFO is being set EOF after there is no >> more data. I tried my client-server app with the snapshot cygwin1.dll, >> and it failed because of this. >> >> It seems to me that the behavior of FIFOs under 1.5.15 was correct, and >> that under both 1.5.16 and the snapshot, FIFOs are now broken. > >FWIW, I just tested your example under Solaris 8 and it works just like >Christopher describes. I think the previous <1.5.15 implementation of fifos represented my ever-evolving understanding of how they are supposed to work. Either that or it was just a bug. (FWIW, I just tried the example on another machine and still see success with 1.5.16.) If you want to more-or-less duplicate the behavior of 1.5.15 you can do something like this: (echo 9&; echo YOUR TEXT HERE) > /tmp/FIFO As long as there is something sitting around which has the fifo open, the cat process will not terminate. Of course, there will be a long running sleep process sitting around in the above example and that may not be desirable. So, there may be a more elegant way to do this. I thought that maybe something like: cat < FIFO 42>FIFO might work since that would cause cat to keep FIFO open for input and output but that just hangs on both cygwin and linux. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
Jerry D. Hedden wrote: [snip] >> However, that said, the above WJFFM. In fact, it works more like linux >> in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after >> printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. > > > I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior you > mentioned with the 'cat' exiting after it reads text. However, this is > a bad thing. It means that the FIFO is being set EOF after there is no > more data. I tried my client-server app with the snapshot cygwin1.dll, > and it failed because of this. > > It seems to me that the behavior of FIFOs under 1.5.15 was correct, and > that under both 1.5.16 and the snapshot, FIFOs are now broken. FWIW, I just tested your example under Solaris 8 and it works just like Christopher describes. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
Christopher Faylor wrote: On Sat, Apr 30, 2005 at 08:38:17PM -0400, Jerry D. Hedden wrote: I have a client-server application written in Perl that reads and writes using FIFOs. It works fine under cygwin-1.5.15-1, but fails under cygwin-1.5.16-1 because it cannot read from the FIFO. To test this, open two shells. In one shell, type: cd /tmp mkfifo FIFO cat In the other shell, you can send text to the first shell using: cd /tmp echo YOUR TEXT HERE >>FIFO After you're done, just ^C in the first window. Under 1.5.15, the above works fine. Under 1.5.16, no text goes through the FIFO. Further, the echo command hangs, and will not terminate with ^C. A 'ps' shows an 'O' for this stuck shell. You have to do a kill -9 on the shell to terminate it. As I mentioned in another enjoyable thread last week, fifos are only just barely working in cygwin. They are still a work in progress. However, that said, the above WJFFM. In fact, it works more like linux in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior you mentioned with the 'cat' exiting after it reads text. However, this is a bad thing. It means that the FIFO is being set EOF after there is no more data. I tried my client-server app with the snapshot cygwin1.dll, and it failed because of this. It seems to me that the behavior of FIFOs under 1.5.15 was correct, and that under both 1.5.16 and the snapshot, FIFOs are now broken. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.16-1: FIFOs broken
On Sat, Apr 30, 2005 at 08:38:17PM -0400, Jerry D. Hedden wrote: >I have a client-server application written in Perl that reads and writes >using FIFOs. It works fine under cygwin-1.5.15-1, but fails under >cygwin-1.5.16-1 because it cannot read from the FIFO. > >To test this, open two shells. In one shell, type: >cd /tmp >mkfifo FIFO >cat >In the other shell, you can send text to the first shell using: >cd /tmp >echo YOUR TEXT HERE >>FIFO > >After you're done, just ^C in the first window. > >Under 1.5.15, the above works fine. > >Under 1.5.16, no text goes through the FIFO. Further, the echo command >hangs, and will not terminate with ^C. A 'ps' shows an 'O' for this >stuck shell. You have to do a kill -9 on the shell to terminate it. As I mentioned in another enjoyable thread last week, fifos are only just barely working in cygwin. They are still a work in progress. However, that said, the above WJFFM. In fact, it works more like linux in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin-1.5.16-1: FIFOs broken
> I have a client-server application written in Perl that reads > and writes using FIFOs. It works fine under cygwin-1.5.15-1, > but fails under > cygwin-1.5.16-1 because it cannot read from the FIFO. > > To test this, open two shells. In one shell, type: > cd /tmp > mkfifo FIFO > cat > In the other shell, you can send text to the first shell using: > cd /tmp > echo YOUR TEXT HERE >>FIFO > > After you're done, just ^C in the first window. > > Under 1.5.15, the above works fine. > > Under 1.5.16, no text goes through the FIFO. Further, the > echo command hangs, and will not terminate with ^C. A 'ps' > shows an 'O' for this stuck shell. You have to do a kill -9 > on the shell to terminate it. FIFOs are not fully implemented in Cygwin yet, but thank you for the test case. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
