Follow-up Comment #4, bug #22861 (project hurd):
The t/io_select_timeout patches in glibc complicate the fix. Now if
glibc/hurd/hurdselect.c (_hurd_select) is called with a timeout and at least
one file descriptor, it passes the current time + the timeout to the servers,
instead of letting __mach_msg time out. And if each server returns
MIG_NO_REPLY to its message loop and so never sends a reply, then _hurd_select
sleeps until interrupted by a signal, regardless of what the timeout was.
I guess the io_select_timeout implementation in each server could just wait
until the timeout occurs (at which time it would send an reply with
select_type=0) or the reply port dies (in which case no reply can be sent, and
any related resources should be freed). As an optimization, the server could
use a timer queue so that the wait does not tie up a thread.
io_select could be implemented in a similar way except with an infinite
timeout, or it could be done with MIG_NO_REPLY as originally planned, I
think.
I removed the workaround from ELinks and tried to reproduce the original
problem but couldn't; it never called select in such a way that the pipe was
only in exceptfds. To test any fix here, one should construct a dedicated
test program instead of relying on ELinks.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?22861>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
