On Thu, 25 Feb 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Joacim" == Joacim Persson <[EMAIL PROTECTED]> writes:
>
> Joacim> On Wed, 24 Feb 1999, Jean-Marc Lasgouttes wrote:
> >> Actually this happens to me on Digital Unix 4.0.
>
> Joacim> Is that SysV-ish or BSD? (just curious)
>
> >From the 'standards' man page, it seems rather SysV-ish (and POSIX and
> XPG).
>
> Joacim> Now, I don't /know/ what goes on inside libforms.
>
> I do (I have the source :).
>
>
> Joacim> I'm told there is a select -- well there have to be one --
> Joacim> but maybe they do something else too, like checking the file
> Joacim> descriptor's buffer for data whenever the select triggers on
> Joacim> it and only call the callback if there actually is something
> Joacim> in the buffer. The libforms manual says the callback is
> Joacim> called when the file descriptor "has data available", but the
> Joacim> author could also have misunderstood the operation of select()
> Joacim> I suppose.
>
> They just call the callback when select triggers on the fd.
thus libforms manual may be wrong regarding FIFOs, but to get back to what
DECs man page said on select ("not necessarily have data available"), I
wonder if that goes for /all/ kinds of file descriptors or if they just
meant file descriptors for /sockets/ that are available for an accept()?
>
> Joacim> Yes it looks a bit like putting jam on the jelly doesn't it?
> Joacim> "Opening a file non-blocking, and then /select/ over it!?!?"
> Joacim> ;)
>
> Didn't I told you that I do not understand it all? %-]
info libc, sections "I/O Overview" and down explains most of the marvels of
streams, pipes, and sockets.
Now, you tell me how to make an istream become unbuffered in STL, that's
what's driving /me/ nuts at the moment. ...cin.setbuf(0,0)? ...nope :P
(The bus drivers are on strike in Sweden, so I'm stuck at home and have
started working on my "vy"-client again -- a vi-like mode for LyX using
lyxserver -- as a pastime)
>
> Joacim> Another strange fact about named pipes is that an open() on
> Joacim> one end won't return until the fifo is open()ed in the other
> Joacim> end too, unless it is opened with O_NONBLOCK. (an unnamed pipe
> Joacim> is allways opened on both ends simultaneously, with pipe(2),
> Joacim> so no broken pipes there)
>
> Maybe the following description from the read() man page can make some
> sense to you...
>
> When attempting to read from an empty pipe (or FIFO):
>
> + If no process has the pipe open for writing, the read() function
> returns 0 (zero) to indicate end-of-file.
>
> + If some process has the pipe open for writing and O_NONBLOCK is set,
> the read() function returns a value of -1 and sets errno to [EAGAIN].
>
> + If some process has the pipe open for writing and O_NONBLOCK is clear,
> the read() function will block until some data is written or the pipe
> is closed by all processes that had opened the pipe for writing.
>
> + [Digital] If some process has the pipe open for writing and O_NDELAY
> is set, the read() function returns a value of -1 and sets errno to
> [EAGAIN].
>
> + [Digital] If some process has the pipe open for writing and O_NDELAY
> is clear, the read() function will block until some data is written or
> the pipe is closed by all processes that had opened the pipe for writ-
> ing.
O_NDELAY is the same thing as O_NONBLOCK. But (-1 != 0) (yields `true' in the
while-statement), so that's not the case here (errno==EAGAIN makes ::callback
return without resetting the connection; you must have gotten ::callback
called AND the following read() in ::callback return 0. (if you had gotten
read()!=0 and errno!=0 i.e. (errno!= 0 && errno != EAGAIN), LyX would have
printed the error message for the errno before resetting the pipe, which it
didn't) Run the debugger on it, trace the return values and the value of
errno in ::callback.
What must have happened is: select triggered on the input pipe file
descriptor, but the read() claimed end-of-file (return 0;); i.e. noone at
the other end; broken pipe. So why is select triggering on a broken pipe?
>
> Joacim> ...maybe if we open it non-blocking, and set it to blocking
> Joacim> /after/ the call to fl_add_io_callback, with fcntl()? Then
> Joacim> the lines for "resetting the connection" could/should probably
> Joacim> be taken out too. I'm not sure what happens when the client
> Joacim> closes its end of the fifo in that case. I'm afraid we must
> Joacim> have a signal handler for SIGPIPE too. :P
>
> If you provide me with a patch, I can try it out.
remove the O_NONBLOCK in the open(), add fcntl(fd,F_SETFL,O_NONBLOCK) on
the next line (or whatever the fd is named). (no need for a signal handler
for SIGPIPE for the reader process, and the "reset connection"-lines can
stay too)
But I don't think that's the way to go actually.
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
