| * duflu dusts off the old netbook in readiness for Mesa 10.3 celebrations | 03:12 | |
| greyback__ | alf_: ping | 10:50 |
|---|---|---|
| === greyback__ is now known as greyback | ||
| alf_ | greyback: Hi | 10:51 |
| greyback | alf_: hey, I've a weird question about signals | 10:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| alf_ | greyback: so, SIGSTOP cannot be captured anyway, so something else is going on | 10:57 |
| 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 | 10:58 |
| 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:00 |
| greyback | alf_: 0.7.3+14.10.20140918.1-0ubuntu1 | 11:01 |
| 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:03 |
| greyback | alf_: ok, thanks. I suspect it's coming externally | 11:04 |
| === ara_ is now known as ara | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:13 |
| kdub_ | alf_, right, that's in PlatformIpcOperations::unpack_buffer(BufferI&, Buffer const&) | 13:16 |
| kdub_ | whoops | 13:17 |
| kdub_ | PlatformIpcOperations::unpack_buffer(BufferIpcMessage&, Buffer const&) | 13:17 |
| alf_ | kdub_: ah, ok, so no separate call | 13:18 |
| kdub_ | right | 13:18 |
| 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:19 |
| kdub_ | oh, and, may as well not link the platforms to protobuf too :) | 13:28 |
| === dandrader__ is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === davmor2_ is now known as davmor2 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!