Yes, the case that I was talking about was the one in which lis_down() fails. A common case of this is when a process is signalled.
But I notice that lis_poll_bits() returns poll bits, not a negative errno. So it becomes a interesting question of what to return when lis_down() "fails". Your code sets POLLERR, which is reasonable from the standpoint of considering lis_poll_bits() in isolation.
The linux sys_poll() function has the following code in it after returning from all the xxx_poll_bits() routines:
err = fdcount;
if (!fdcount && signal_pending(current))
err = -EINTR;
That is, it returns EINTR if the process is signalled AND if there are no file descriptors ready.
That would suggest returning 0 from lis_poll_bits() when the lis_down() call fails. Returning anything non-zero runs the risk of the process never getting to perceive the EINTR return.
-- Dave
At 01:20 PM 6/1/2004, dan_gora wrote:
--- Dave Grothe <[EMAIL PROTECTED]> wrote:
> You are definitely on the right track. The lis_down() "failures" probably
> relate to signals. Do you see EAGAIN as the errno upon return from poll()?
Do you mean when the lis_down() fails? I'm not sure about that, but I can
check it. poll() should never return with EAGAIN unless something is wrong,
correct? That is, do I have to somehow correlate the failure in
lis_poll_bits() to the return value from poll()? Or can I just assume that
if poll() returns with -1 and sets errno that it was because I bailed out of
lis_poll_bits() with an error? I guess I could set a breakpoint in the
debugger for the error case and just walk though it until I get back from
poll() and see what happens. It might take a day or two for me to get a
chance to do this however.
thanks-
dan
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
