=== Md_ is now known as Md [16:38] http://tobytripp.github.com/meeting-ticker/ [17:43] erk [17:43] it looks like LP was spamming everyone in the upstart-devel team with bugs [17:43] is that right? [17:46] Keybuk: I suppose... I have it filtered to a folder so it didn't bother me much [17:47] the idea was for maintainers to be able to modify bugs [17:47] though I guess if you don't mind getting cc'd on them, I can leave it [17:47] well that's my vote. dunno how ion / plautrba / mbiebl feel [17:48] Keybuk: in furtherance of queue-ifying everything in Upstart I'm also reworking how blocking is done. [17:49] oh right, what you thinking [17:49] Keybuk: basically I'm introducing a "trigger table" [17:50] Keybuk: a trigger is 1) a list of events that will fire it (event operator with only 'or's basically) 2) a callback, 3) a "recurring" flag (explain in a moment) [17:51] Keybuk: when an event is processed (an event can now be an "external" event, which is what they all are now, or another type of event like a start request), its simply matched against any of those triggers. [17:52] if it matches one, that callback is run, and then the trigger is removed (unless "recurring" is set, in which case it stays to be fired again) [17:52] once the event has been run through this table, its discarded. That's the big change. [17:53] so queuing up commands and events in the same way basically? [17:53] Keybuk: the queueing is the same. the difference is theres no "pending" [17:53] Keybuk: An event is handled immediately and dropped [17:53] Keybuk: part of that handling though can be to set up another trigger [17:53] hmm, I used the event queue deliberately though [17:54] of course, the reason I did that may be invalid now [17:54] but the idea was to prevent Upstart from being in the situation where it'd would endlessly follow state changes without returning through the main loop [17:54] otherwise if job's A and B flip-flopped, it could just loop happily though them forever generating events [17:55] Keybuk: oh I see what you're missing [17:55] Keybuk: the event is "handled" immediately, but it may be incomplete when we're done with it [17:55] Keybuk: its sort of "stateless" [17:55] Keybuk: I also filter the messages into a separate folder [17:55] so I don't mind much receiving the messages [17:56] Some of them are actually interesting ;-) [17:57] Keybuk: its like this, lets say we get a "start foo" event request. This fires the appropriate recurring trigger which starts foo. That does the forking and the execing, and then it sets up another trigger that says "on started foo do (send method reply, cleanup dbus connection)" [17:57] I'm not sure I quite follow, but it sounds reasonable [17:57] I was never happy with the blocking stuff [18:00] Keybuk: a question: why did you make the event queue a pointer to a list and then allocate it with a constructor. Couldn't you have just allocated a static list head? Or was it because you wanted it to hold references to other things? [18:01] just general style === Keybuk changed the topic of #upstart to: Upstart 0.6.1 "Born in the wagon of a travelling show" | http://upstart.ubuntu.com/ [18:16] This release does not have a changelog [18:16] ^^uncharacteristic of you, Keybuk [18:16] though it looks to be few changes [18:16] "does not have a changelog" ? [18:17] oh, on LP - it keeps throwing them away [18:17] * Keybuk pastes *AGAIN* [18:18] hmm 0.6.0 went missing too [18:18] and 0.5.3 got swapped [18:18] I bet they've broken some LP schema here [18:19] Keybuk: remember when I was giving Canonical crap about not open sourcing this thing? I take it back. Keep it plz. [18:19] lol [18:19] has it been opened yet? [18:24] Keybuk: I think bits of it have been creeping out. I haven't heard anyone make noise about it in awhile. [18:25] Keybuk: you have more patches in this dbus release than any other dev. Do you actually work on dbus or is it really all to make Upstart work? [18:27] just bugs and issues I'm finding when doing Upstart [18:27] I have upstream commit rights to D-Bus though [18:28] Keybuk: kinda sad that merely attempting to use the software yielded this many issues, after its been out that long. [18:28] 2-space tabs are also kinda sad, but we'll save that for another day [18:28] sadmac: Upstart uses it in a slightly different way to other programs [18:29] I was probably the first person to test D-Bus *without* wanting it to exit() on disconnect from the daemon ;P [18:29] so I find a few bugs in that code [18:29] the test suite is pretty rigorous about forcing things to clean up, so I found a few places where libdbus didn't actually get cleaned up on dbus_shutdown() [18:30] and the malloc testing is pretty brutal too - most people abort() if malloc returns NULL :p [18:30] the other major stuff is the timeout code [18:30] yeah. more an RFE [18:30] Keybuk: so, about that kernelspace dbus thing :) [18:30] sadmac: are you running 0.6.x now? [18:33] if so, compare [18:33] Keybuk: no. I actually just got my home box up to F11 (had some storage juggling I wanted to do) and then I have to port the job defs [18:33] oh [18:33] I'll paste then [18:33] quest scott% sudo time sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done' [18:33] 0.61user 0.17system 0:01.32elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k [18:33] 0inputs+0outputs (0major+39960minor)pagefaults 0swaps [18:33] quest scott% time sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done' [18:33] sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done' 1.68s user 0.28s system 14% cpu 13.419 total [18:33] -- [18:33] both running 100 initctl list commands [18:34] first is as root, so is directly between init and initctl - takes 1.32s [18:34] second is as a normal user, so goes via the bus daemon - takes 13.419s! [18:34] bear in mind that both are using the D-Bus protocol and libdbus [18:34] the bus daemon overhead is huge [18:34] Keybuk: that's...noticeable. problematic even [18:35] yeah [18:35] I'd be very supportive of AF_DBUS ;) [18:35] Keybuk: tell bill to make me a developer again and I'll do it. [18:36] * sadmac had this funny idea that graduating would give him the time to do things [18:36] yeah, I've heard that from students before [18:37] "when I graduate, I won't be so busy" [18:37] I need to be more of an asshole so people will stop socializing with me. Then I'll get code written [18:37] stop going outside. That's how software gets done [18:40] yeah [18:40] but that's not the worst thing to happen to a software developer [18:40] I’m not in ~upstart-devel (and i wouldn’t belong there anyway, since i don’t manage to contribute much with this health), but now that it was mentioned, i subscribed to the bug mail anyway. :-P [18:41] ion: I can add you if you like - contributing to bug triage is more than welcome [18:41] the team's there to let people set bug importances and the like === robbiew is now known as robbiew-afk [18:42] Yeah, sure [18:42] ion: I didn't know you had health problems. Are you ok? [18:45] Nothing acute. The current diagnosis is F48.0 http://apps.who.int/classifications/apps/icd/icd10online/?gf40.htm+f480 [18:48] ion: sorry to hear that [18:49] Thanks [19:46] plautrba: did you push those 0.3.11 packages when you built them? [20:04] mbiebl: how is "upstart in debian" progressing? === robbiew-afk is now known as robbiew [21:46] Md: made the dbus 1.2.16 upload yesterday [21:47] (which spectacularly failed because of the debhelper fuckup) [21:47] that's now fixed [21:47] I expect 0.6.1 to hit unstable in the next couple of days. [21:48] Md: we had some good discussions on the boot performance sprint in london [21:50] pere had some concerns, but it's not completely unrealistic that we might switch to upstart even for squeeze [21:54] * Bump dpkg dependency to 1.2.16 [21:54] keybuk: You mean dbus? :-) [23:24] err, probably