<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 13, 2014 at 4:11 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>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.<br><br></div></div></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div></div><div>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.<br></div></div></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​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.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Cheers,<br>Chris<br></div></div></div></div></div>