User1: http://tobytripp.github.com/meeting-ticker/
User2: erk
User2: it looks like LP was spamming everyone in the upstart-devel team with bugs
User2: is that right?
User3: User2 I suppose... I have it filtered to a folder so it didn't bother me much
User2: the idea was for maintainers to be able to modify bugs
User2: though I guess if you don't mind getting cc'd on them, I can leave it
User3: well that's my vote. dunno how ion / plautrba / mbiebl feel
User3: User2 in furtherance of queue-ifying everything in Upstart I'm also reworking how blocking is done.
User2: oh right, what you thinking
User3: User2 basically I'm introducing a "trigger table"
User3: User2 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)
User3: User2 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.
User3: 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)
User3: once the event has been run through this table, its discarded. That's the big change.
User2: so queuing up commands and events in the same way basically?
User3: User2 the queueing is the same. the difference is theres no "pending"
User3: User2 An event is handled immediately and dropped
User3: User2 part of that handling though can be to set up another trigger
User2: hmm, I used the event queue deliberately though
User2: of course, the reason I did that may be invalid now
User2: 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
User2: otherwise if job's A and B flip-flopped, it could just loop happily though them forever generating events
User3: User2 oh I see what you're missing
User3: User2 the event is "handled" immediately, but it may be incomplete when we're done with it
User3: User2 its sort of "stateless"
User4: User2 I also filter the messages into a separate folder
User4: so I don't mind much receiving the messages
User4: Some of them are actually interesting ;-)
User3: User2 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)"
User2: I'm not sure I quite follow, but it sounds reasonable
User2: I was never happy with the blocking stuff
User3: User2 a questUser1 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?
User2: 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/
User3: This release does not have a changelog
User3: ^^uncharacteristic of you, Keybuk
User3: though it looks to be few changes
User2: "does not have a changelog" ?
User2: oh, on LP - it keeps throwing them away
 * Keybuk pastes *AGAIN*
User2: hmm 0.6.0 went missing too
User2: and 0.5.3 got swapped
User2: I bet they've broken some LP schema here
User3: User2 remember when I was giving Canonical crap about not open sourcing this thing? I take it back. Keep it plz.
User2: lol
User2: has it been opened yet?
User3: User2 I think bits of it have been creeping out. I haven't heard anyone make noise about it in awhile.
User3: User2 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?
User2: just bugs and issues I'm finding when doing Upstart
User2: I have upstream commit rights to D-Bus though
User3: User2 kinda sad that merely attempting to use the software yielded this many issues, after its been out that long.
User3: 2-space tabs are also kinda sad, but we'll save that for another day
User2: User3 Upstart uses it in a slightly different way to other programs
User2: I was probably the first person to test D-Bus *without* wanting it to exit() on disconnect from the daemon ;P
User2: so I find a few bugs in that code
User2: 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()
User2: and the malloc testing is pretty brutal too - most people abort() if malloc returns NULL :p
User2: the other major stuff is the timeout code
User3: yeah. more an RFE
User3: User2 so, about that kernelspace dbus thing :)
User2: User3 are you running 0.6.x now?
User2: if so, compare
User3: User2 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
User2: oh
User2: I'll paste then
User2: quest scott% sudo time sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done'
User2: 0.61user 0.17system 0:01.32elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k
User2: 0inputs+0outputs (0major+39960minor)pagefaults 0swaps
User2: quest scott% time sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done'
User2: 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
User2: --
User2: both running 100 initctl list commands
User2: first is as root, so is directly between init and initctl - takes 1.32s
User2: second is as a normal user, so goes via the bus daemon - takes 13.419s!
User2: bear in mind that both are using the D-Bus protocol and libdbus
User2: the bus daemon overhead is huge
User3: User2 that's...noticeable. problematic even
User2: yeah
User2: I'd be very supportive of AF_DBUS ;)
User3: User2 tell bill to make me a developer again and I'll do it.
 * sadmac had this funny idea that graduating would give him the time to do things
User2: yeah, I've heard that from students before
User2: "when I graduate, I won't be so busy"
User3: I need to be more of an asshole so people will stop socializing with me. Then I'll get code written
User3: stop going outside. That's how software gets done
User2: yeah
User2: but that's not the worst thing to happen to a software developer
User1: 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
User2: User1 I can add you if you like - contributing to bug triage is more than welcome
User2: the team's there to let people set bug importances and the like
User1: Yeah, sure
User3: User1 I didn't know you had health problems. Are you ok?
User1: Nothing acute. The current diagnosis is F48.0 http://apps.who.int/classifications/apps/icd/icd10online/?gf40.htm+f480
User3: User1 sorry to hear that
User1: Thanks
User3: plautrba: did you push those 0.3.11 packages when you built them?
User5: User4 how is "upstart in debian" progressing?
User4: User5 made the dbus 1.2.16 upload yesterday
User4: (which spectacularly failed because of the debhelper fuckup)
User4: that's now fixed
User4: I expect 0.6.1 to hit unstable in the next couple of days.
User4: User5 we had some good discussions on the boot performance sprint in london
User4: pere had some concerns, but it's not completely unrealistic that we might switch to upstart even for squeeze
User1: * Bump dpkg dependency to 1.2.16
User1: keybuk: You mean dbus? :-)
User2: err, probably
upstart
Ubuntu IRC