select() and pflocal (was: The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd)

[olafBuddenhagen]

Hi,

Thanks for debugging this! Forwarding it to the appropriate list.

-antrik-

----- Forwarded message from Kalle Olavi Niemitalo <kon@iki.fi> -----

Date: Wed, 26 Dec 2007 17:44:37 +0200
From: Kalle Olavi Niemitalo <kon@iki.fi>
Subject: Re: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
        Debian GNU/Hurd
To: debian-hurd@lists.debian.org
Cc: ELinks text WWW browser development mailing list 
<elinks-dev@linuxfromscratch.org>

After some peeking around with QEMU and GDB, I think I have found
the bug.  rpctrace shows:

  90->io_select_request (5)task7590->mach_port_allocate (3) = 0 pn{ 28}
task7590->mach_port_move_member (pn{ 24} pn{ 28}) = 0
 114->io_select_request (5)task7590->mach_port_move_member (pn{ 29} pn{ 
28})reply(131:io_select_request)->io_select_reply (0 1);
reply? 122 > 0
 117->io_select_request (4)task7590->mach_port_move_member (pn{ 27} pn{ 
28})reply(131:io_select_request)->io_select_reply (0 0);
reply? 122 > 0

_hurd_select in glibc considers the io_select_reply (0 0) a
"bogus answer": if the pipe is not ready for any I/O, then it
should not have responded yet.  And so, glibc substitutes
SELECT_ALL, which includes SELECT_URG and triggers free_itrm in
ELinks.

Why did pflocal send the bogus answer, then?  When *select_type
is initially SELECT_URG without other flags, S_io_select in
hurd/pflocal/io.c first resets *select_type to zero and then
calls pipe_pair_select in hurd/libpipe/pipe.c.  That notices
*select_type is neither SELECT_READ nor SELECT_WRITE, and
apparently assumes it is SELECT_READ | SELECT_WRITE and waits for
either condition.  One of the conditions is satisfied, but
*select_type remains zero, and S_io_select then propagates the
zero to the io_select_response.

It seems to me that you Hurd people have three ways to fix this:

(a) Change _hurd_select to completely ignore responses that
    have select_type=0.  Don't even set SELECT_RETURNED.
    This would make the timeout more complex to implement.

(b) Change pflocal to detect when io_select_request is asking
    solely for events that cannot ever occur, and sleep until
    the caller closes the reply port.  Similar changes may be
    needed in other servers.

(c) As in (b) but instead of sleeping, just discard the send-once
    right without sending any response, and return the thread to
    more productive use.  I don't know how difficult that would
    be with mig.



----- End forwarded message -----