Re: Abolishing sleeps in issignal()

On Mon, 8 Oct 2007, Jeff Roberson wrote:

During the work on thread lock I observed that there is a significant amount of locking involved in our signal paths right now. And these locks also show up contended in many workloads. Furthermore, requiring a DEF mutex complicates sleep queues by forcing them to drop the spinlock to check for signals and then check for races.

The current issignal() code will actually msleep in the case of a stopevent() requested by the debugger. This is fine for signals that would normally abort the sleep anyway, but SIGSTOP actually leaves the thread on the sleep queue and tries to resume the sleep after the stop has cleared. So SIGSTOP combined with a stopevent() actually breaks because the stopevent() removes the thread from the sleep queue. I'm not certain what the failure mode is currently, but I'm certain that it's wrong.

What I'd like to do is stop sleeping in issignal() all together. For regular restartable syscalls this would mean failing back out to ast() where we'd then handle the signals including SIGSTOP. After SIGCONT we'd then restart the syscall. For non-restartable syscalls we could have a special issignal variant that is called when msleep/cv_timedwait_sig return interrupted that would check for SIGSTOP/debugger events and sleep within a loop retrying the operation. This would preserve the behavior of debugging events and SIGSTOP not aborting non-restartable syscalls as they do now.

Once we have moved the location of the sleeps it will be possible to check for signals using a spinlock without dropping the sleep queue lock in sleepq_catch_signals().

What I'd like from readers on arch@ is for you to consider if there are other cases than non-restartable syscalls that will break if msleep/sleepqs return EINTR from SIGSTOP and debug events. Also, is there an authoritative list of non-restartable syscalls anywhere? It's just those involving timevals right? nanosleep/poll/select/kqueue.. others?

I would consult the POSIX spec; it may be of some value to you. Generally, any syscall that can block should be able to restart
the syscall without the application handling EINTR. On the flip
side, any syscall that can be guaranteed to complete in a short
time should not return EINTR, but should delay signal delivery
until after syscall completion. Some functions are guaranteed
by POSIX to not return EINTR (e.g., getpid & getuid).

See:

http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap02.html#tag_03_02_04

I don't know if that link will work...

--
DE
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Abolishing sleeps in issignal()
    ... This is fine for signals that would normally abort the sleep anyway, but SIGSTOP actually leaves the thread on the sleep queue and tries to resume the sleep after the stop has cleared. ... For non-restartable syscalls we could have a special issignal variant that is called when msleep/cv_timedwait_sig return interrupted that would check for SIGSTOP/debugger events and sleep within a loop retrying the operation. ...
    (freebsd-arch)
  • Re: basic signal problem
    ... But I Dont understand one thing in signals. ... like pipes and FIFO's are also used for communication of data ... > isn't a signal for invalid mathematical operations involving integers. ... > EINVAL or EFAULT for most syscalls (there are exceptions to this rule so ...
    (comp.unix.programmer)
  • Re: POSIX signal handling versus traditional signal handling
    ... > to get reliable signals ... SysV sigsetdiffers from BSD signalin whether or not restartable ... syscalls are actualy restarted when the signal handler terminates. ...
    (comp.unix.programmer)