On Wed, 24 Feb 1999, Jean-Marc Lasgouttes wrote:
> Actually this happens to me on Digital Unix 4.0.
Is that SysV-ish or BSD? (just curious)
>
> A bit of search of the select() man page reveals the following:
>
> [Digital] Objects ready for the requested operation are those which the
> operation would not block and not necessarily those which have data avail-
> able for the operation.
>
> This explains two things:
>
> - the callback may be called when there is nothing to read
>
> - when the server used to work for me, it used a lot of CPU time. I
> guess it was because the callback was called all the time without any
> data to read.
The problem with select() is that it's not standardised at all. It's an
BSD:ism that has been adapted to SysV ...with variations. (Linux
does strange things with the timeout struct that noone else does for
instance).
Now, I don't /know/ what goes on inside libforms. I'm told there is a
select -- well there have to be one -- but maybe they do something else too,
like checking the file descriptor's buffer for data whenever the select
triggers on it and only call the callback if there actually is something in
the buffer. The libforms manual says the callback is called when the
file descriptor "has data available", but the author could also have
misunderstood the operation of select() I suppose.
>
> I guess this is related to the fact that the fd is open with:
>
> infd = open(tmp.c_str(), O_RDONLY|O_NONBLOCK);
>
> However, my knowledge of pipes stops there. I tried blindly to remove
> the O_NONBLOCK, but it is obviously not the right idea...
Yes it looks a bit like putting jam on the jelly doesn't it? "Opening a
file non-blocking, and then /select/ over it!?!?" ;)
Another strange fact about named pipes is that an open() on one end won't return
until the fifo is open()ed in the other end too, unless it is opened with
O_NONBLOCK. (an unnamed pipe is allways opened on both ends simultaneously,
with pipe(2), so no broken pipes there)
...maybe if we open it non-blocking, and set it to blocking /after/ the call
to fl_add_io_callback, with fcntl()? Then the lines for "resetting the
connection" could/should probably be taken out too. I'm not sure what happens
when the client closes its end of the fifo in that case. I'm afraid we
must have a signal handler for SIGPIPE too. :P
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
