ongoing refactorings

Chris Jones jones.chris.g at
Mon Oct 13 16:59:19 PDT 2014

On Mon, Oct 13, 2014 at 4:11 PM, Robert O'Callahan <robert at>

> Right now I'm working on a somewhat speculative refactoring. In many
> places we call Task methods that eventually result in a did_waitpid call
> indicating a waitpid returned a wait status for the Task. Code in the call
> chain is responsible for handling the various possible kinds of wait status
> (normally a signal or various ptrace events). It's often difficult to track
> what is responsible for handling various events and ensure all possible
> events are handled. I'd like to clean this up. My current idea is to add a
> WaitStatus object generated by did_waitpid and passed up the call chain. It
> will offer methods for interrogating the wait status but more importantly
> it will represent an obligation to handle the wait status. I intend to add
> a flag to the object to indicate if the status was handled, and then the
> destructor can assert that it was.
Another way you could do that kind of thing is with an RAII-style "status
lock" or something, declared in the scope of where we're going to handle
the status change.  The handlers could stack.  Then code that wanted to
explicitly drop drop signals, like go_to_happy_place() currently, could
declare its own RAII helper, and there could be a default handler at
"top-level" that queued unhandled signals for delivery etc.  I'm kind of
waving my hands on this though, haven't thought too deeply about it.

> BTW I got the idea to do this while I was looking into introducing a queue
> of pending signals instead of the current incomplete hacks around the
> problem. Introducing a queue of pending signals is currently quite
> difficult since there are many places where a waitpid could return a new
> pending signal and it's difficult to verify we do the right thing at all
> those sites. We can't just have did_waitpid automatically push a signal
> onto the queue since under some call stacks certain signals need special
> treatment.

​Another tricky part of queuing signals is getting linux queuing semantics
correct.  IIRC the non-realtime signals can each have two deliveries
pending, and the real-time signals queue arbitrarily in the way you would
expect.  But, (i) I don't know how this is surfaced through the ptrace API,
and (ii) in what order does linux deliver pending signals, non-realtime and
realtime?  I never wrote test programs to explore these.  *Some* queuing
solution that's unsound wrt linux semantics is probably better than
nothing, though.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the rr-dev mailing list