[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hurd-bug
Subject:    [bug #22861] bogus answer from pflocal to io_select SELECT_URG
From:       Kalle Olavi Niemitalo <INVALID.NOREPLY () gnu ! org>
Date:       2016-07-16 13:46:38
Message-ID: 20160716-134637.sv38928.41813 () savannah ! gnu ! org
[Download RAW message or body]

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/


[prev in list] [next in list] [prev in thread] [next in thread]