ongoing refactorings

Robert O'Callahan robert at
Mon Oct 13 18:00:36 PDT 2014

On Tue, Oct 14, 2014 at 12:59 PM, Chris Jones <jones.chris.g at>

> 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.

I think a stack of handler objects could get confusing. I'd like to be able
to look at a piece of code that does a continue-and-wait and locally reason
about which status changes are handled and how they're handled. Some
encapsulation of behavior is still possible by defining utility functions
(or methods of WaitStatus) that handle certain cases in defined ways (e.g.
ignoring certain specific signals during replay) and calling these

>> 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.

Yeah. I hope we can get away with a simple signal scheduling approach.

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the rr-dev mailing list