#15193: pselect() is not interrupted by signal
--------------------------+------------------------------
Reporter: simonsouth | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: System/POSIX | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: x86-64 |
--------------------------+------------------------------
[http://man7.org/linux/man-pages/man2/select.2.html POSIX's pselect()
function] is meant to block until either a file descriptor becomes ready
for I/O or a signal is received. Haiku's implementation currently fails in
the latter case, seeming to enter an infinite loop instead of returning
when a signal arrives.
I'm attaching a program that demonstrates this. The program
* Attaches a handler for the SIGCHLD signal, which is sent automatically
when a child process terminates;
* Blocks SIGCHLD, causing the signal to be held by the OS when it arrives;
* Spawns a child process that exits immediately, raising SIGCHLD; and
* Calls pselect() with an empty signal mask (temporarily unblocking
SIGCHLD), waiting for STDIN to become ready.
The program should exit immediately when it's run, as the SIGCHLD signal
should interrupt pselect() right away without a chance for the user to
enter anything. Linux shows the correct behaviour:
{{{
Child process is exiting
Waiting for Enter or signal...
SIGCHLD received
pselect() returned -1: Interrupted system call (4)
}}}
On Haiku the program hangs at pselect(), with the thread consuming about
30% of the CPU's time:
{{{
Child process is exiting
Waiting for Enter or signal...
}}}
Pressing Enter causes the program to exit, so pselect() is correctly
monitoring the file descriptor.
From the kernel debugger the thread seems to get stuck in a loop when the
signal arrives, continually re-executing [https://git.haiku-
os.org/haiku/tree/src/system/kernel/wait_for_objects.cpp?h=hrev53259#n428
common_select()]. Stepping through part of the function, it does seem to
correctly recognize the SIGCHLD signal has arrived, and returns
B_INTERRUPTED (or tries to).
My theory is the thread is then left in an "interrupted system call"
state, triggering some other part of the system to restart the call
automatically. But because pselect() is //meant// to be interrupted by
signals this prevents it from ever making progress or returning to its
caller. I haven't been able to verify this, though.
Any advice on where I should be looking next to debug this?
--
Ticket URL: <https://dev.haiku-os.org/ticket/15193>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
