[03:12]  * duflu dusts off the old netbook in readiness for Mesa 10.3 celebrations
[10:50] <greyback__> alf_: ping
[10:51] <alf_> greyback: Hi
[10:51] <greyback> alf_: hey, I've a weird question about signals
[10:52] <greyback> during startup unity8/mir raises SIGSTOP on itself to tell upstart that it is running, and so clients can start connecting to it
[10:52] <greyback> this works perfectly fine
[10:53] <greyback> I'm moving that SIGSTOP emission to later in the startup, after Mir's event loop is definitely running
[10:53] <greyback> again, works perfectly fine with upstart
[10:53] <greyback> but we've an autopilot test that tests this behaviour too
[10:54] <greyback> so it executes unity8 manually, and waits for it to SIGSTOP itself, then resumes it
[10:54] <greyback> however, in this case, it appears the Mir signal handling code captures the signal
[10:55] <greyback> which is weird, as I didn't think it would capture SIGSTOP!
[10:55] <greyback> do you think there's some raciness here?
[10:57] <alf_> greyback: so, SIGSTOP cannot be captured anyway, so something else is going on
[10:58] <greyback> as I'm not using run_mir, qtmir registers a signal handler for SIGINT and SIGTERM in Mir's event loop - and that seems to fire
[11:00] <greyback> alf_: hmm, it might be unrelated indeed. Something just caught my eye
[11:00] <greyback> I will dig a bit more, sorry for interruption
[11:00] <alf_> greyback: no worries, which mir version are you using?
[11:01] <greyback> alf_: 0.7.3+14.10.20140918.1-0ubuntu1
[11:03] <alf_> greyback: ok, so the only way for Mir to raise a SIGTERM to itself is at mir::terminate_with_current_exception(), you could check if that is being called, otherwise the signal comes externally
[11:04] <greyback> alf_: ok, thanks. I suspect it's coming externally
[13:13] <alf_> kdub_: Hi! @ read-from-buffer-msg , what's the API for returning a buffer going to look like? Something like PlatformIpcOperations::release_buffer(BufferIpcMessage& message) ?
[13:16] <kdub_> alf_, right, that's in PlatformIpcOperations::unpack_buffer(BufferI&, Buffer const&)
[13:17] <kdub_> whoops
[13:17] <kdub_> PlatformIpcOperations::unpack_buffer(BufferIpcMessage&, Buffer const&)
[13:18] <alf_> kdub_: ah, ok, so no separate call
[13:18] <kdub_> right
[13:19] <kdub_> I mean, BufferIpcMessage is somewhat unneeded in the current state of the code
[13:19] <kdub_> because we don't have anything other than protobuf
[13:19] <kdub_> but, may as well keep the ipc abstractions around
[13:28] <kdub_> oh, and, may as well not link the platforms to protobuf too :)