[10:19] <sadmac> Keybuk: good morning
[10:19] <Keybuk> morning
[10:19] <Keybuk> happy new year
[10:20] <sadmac> Keybuk: you too
[10:21] <sadmac> Keybuk: just pushed events-related code to my state machine prototype
[10:21] <sadmac> Keybuk: so what's up with that secret kernel patch? :)
[10:23] <ion_> I want to know, too
[10:24] <Keybuk> I posted it to lkml already
[10:24] <Keybuk> http://lkml.org/lkml/2008/12/27/80
[10:25] <Keybuk> (patch is in my in-reply-to message)
[10:29] <sadmac> Keybuk: ah. I misthunderbirded
[10:29] <Keybuk> misthunderbirded?
[10:30] <Keybuk> v. to use the wrong mail client
[10:30] <Keybuk> ? :p
[10:30] <sadmac> probably the case
[10:30]  * Keybuk likes the fact the objections to that patch all come from @redhat.com :p
[10:30] <sadmac> Keybuk: well it is lkml :P
[10:31] <Keybuk> as I keep pointing out, if we do so well, you guys give up - we're *screwed*! :p
[10:31] <sadmac> heh.
[10:34] <sadmac> Keybuk: well, now that I've implemented large chunks of the state machine, I've found it to be even less quirky and more simple than I thought.
[10:34] <sadmac> I've been able to nudge out a lot of the semi-strange behavior.
[10:38] <Keybuk> you've been working during the break, haven't you? :p
[10:38] <Keybuk> that's naughty
[10:39] <sadmac> Keybuk: well, I became almost totally noctournal. Nobody's around to party with between 3 and 7am
[10:39] <Keybuk> odd
[10:39] <Keybuk> I returned to something like normal UK waking hours
[10:40] <sadmac> heh
[10:45] <soren> Keybuk: I'm looking at that patch, and can't help but wonder if there's a mechanism for reparenting a process to a different process than pid 1?
[10:45] <sadmac> soren: check the clone() manpage. I almost want to say I saw something like that in there
[10:46] <sadmac> I might be thinking of the option to signal the parent with something other than sigchld though
[10:47] <sadmac> the most fun part of my waitfd patch: read returns ECHILD
[10:47] <sadmac> took a bit to convince myself that was legal
[10:47] <soren> Keybuk: I understand that if it only works for init, the code would just never be triggered if another process has done the PR_SET_ADOPTSIG thing, and that there's no particular reason to hardcode anything like that, but still it left me wondering.
[10:47] <Keybuk> it's the same mechanism
[10:47] <Keybuk> that's why the 1 isn't hardcoded, but uses a child_reaper variable
[10:48] <Keybuk> you'd generally not use SIGCHLD for that notification, since they're not queued
[10:48] <Keybuk> you'd use SIGRTMIN+n
[10:52] <soren> I don't think I get it. How can a process other than init adopt a process?
[10:54]  * sadmac wonders what happens if you clone with CLONE_PARENT from init...
[11:50] <Keybuk> soren: you're forgetting that in Linux, threads are just processes :p
[11:50] <Keybuk> so when a thread parent dies, it's reparented to another thread in the same group, not init
[11:51] <Keybuk> sadmac: init's ppid is 1, so nothing - you get a child of init
[11:51] <sadmac> Keybuk: I was goig to mention that, but I think he wanted to know if there was a way to explicitly set where a child will be reparented
[11:51] <sadmac> Keybuk: ah
[11:52] <sadmac> Keybuk: what about unices like (I think) HPUX that display a system_idle process with pid 0
[11:52] <sadmac> does that not appear as the parent of anything?
[11:53] <Keybuk> does HPUX even have clone() ? :p
[11:53] <sadmac> nobody has clone
[11:53] <sadmac> that's just us
[11:53] <Keybuk> so who cares? :p
[11:53] <sadmac> someone at HP I'd imagine
[11:54] <Keybuk> Upstart doesn't work on HPUX, so EOFFTOPIC :p
[11:54] <sadmac> Linux also has a system idle process of a kind I believe, but it doesn't appear in ps.
[11:54] <sadmac> it may not be a "process" of any real sort.
[11:55] <Keybuk> actually, I'm lying
[11:55] <Keybuk> init has a ppid of 0
[11:55] <sadmac> ah. thought so
[11:55] <sadmac> graphs with loops feels very un-unix
[11:55] <Keybuk> Linux has kernel threads, they are all children of kthreadd
[11:55] <Keybuk> which is pid=2, ppid=0
[11:57] <sadmac> ah
[12:00] <Keybuk> we looked
[12:00] <Keybuk> summary
[12:00] <Keybuk> "Don't do that then"
[12:00] <Keybuk> it'd be ok until the clone exited, at which point you'd maybe get an OOPS or a PANIC :)
[12:01] <sadmac> add that to the list of "things to make an intern patch when you're bored"
[12:02] <sadmac> yeah, I could see that reading as an init crash
[12:06] <sadmac> There's something kind of sad about all of APL being in unicode
[12:06] <sadmac> not quite as sad as the klingon alphabet, but still...
[12:08] <Keybuk> APL?
[12:09] <sadmac> Keybuk: "A Programming Language"
[12:09] <Keybuk> what's wrong with unicode?
[12:09] <sadmac> Keybuk: there's nothing wrong with unicode per se
[12:09] <sadmac> Keybuk: APL has no textual commands
[12:10] <sadmac> Keybuk: its all symbols. some greek ones, some not even in any alphabet
[12:10] <Keybuk> ah, how silly
[12:10] <sadmac> Keybuk: its the esoteric programming language that saw production time
[12:10] <sadmac> Enterprise Brainfuck
[12:11] <sadmac> Keybuk: it was reeeeely good at matrix operations, which was good for getting certain tasks done in a hurry.
[12:11] <sadmac> http://en.wikipedia.org/wiki/File:LifeInApl.gif
[12:11] <sadmac> ^^conway's game of life
[12:11] <Keybuk> does it use the Unicode Interrobang character as an exception operator?
[12:12] <sadmac> dunno. It predates unicode by about 30 years, so it wouldn't have drawn the inspiration from there
[12:13] <Keybuk> n < 2 → ⁈
[12:13] <ion_> That’s not an interrobang.
[12:13] <sadmac> N is less than 2 implies WTF
[12:13] <Keybuk> 1 + 1 ≠ 2 → ‼
[12:13] <Keybuk> ion_: yes it is?
[12:14] <ion_> ‽
[12:14] <sadmac> ⸘
[12:14] <sadmac> where is your god now?
[12:14] <Keybuk> ah, right
[12:15] <Keybuk> we can use utf-8 in C now, right ?
[12:15] <ion_> What i still don’t know is why Unicode has white smiling and frowning face, but only a black smiling face.
[12:15] <ion_> faces
[12:15] <sadmac> ion_: I blogged on this once
[12:16] <ion_> Oh
[12:16] <sadmac> ion_: http://screwyouenterpriseedition.blogspot.com/2008/02/worst-of-unicode.html
[12:17] <ion_> Yeah, just found it with google.
[12:17] <Keybuk> most of Unicode's symbol characters are inherited from other standard sets
[12:18] <Keybuk> I mean
[12:19] <Keybuk> you're talking about a character set that has an entire code block reserved for "Byzantine Musical Symbols" and you're complaining about its smiley faces
[12:19] <sadmac> Keybuk: I believe I did mention the klingon alphabet earlier
[12:19] <sadmac> Keybuk: and there are musical instrument companies open today that were around during the byzantine empire
[12:20] <sadmac> (World's oldest corporation: Zildjian)
[12:21] <Keybuk> Unicode doesn't have space for Klingon
[12:22] <Keybuk> that's nowhere near the oldest company!
[12:23] <Keybuk> there are European breweries older than that! :p
[12:39] <sadmac2> Keybuk: when does fork return EBUSY?
[12:39] <sadmac2> or whatever equates to Resource temporarily unavailable
[12:40] <Keybuk> memory limits, process limits, etc.
[12:41] <sadmac2> hmm
[12:41] <sadmac2> left my workstation running over the break
[12:42] <sadmac2> and my login session appears to be unwell
[12:46] <sadmac2> heh, the whole python state machine is 390 lines
[14:29] <sadmac2> I have a real desk now!
[14:31] <sadmac2> Keybuk: what do you think the interface for waitfd should look like?
[14:33] <Keybuk> waitfd(flags)
[14:33] <Keybuk> gives you an fd
[14:33] <Keybuk> you read() something like siginfo_t with all the expanded status information
[14:34] <sadmac2> Keybuk: its more the list of pids to wait on that concerns me
[14:35] <Keybuk> how do you mean?
[14:36] <sadmac2> Keybuk: do you always want to wait on /all/ children with waitfd, or do you want some of the selection power that you have with waitpid&co
[14:36] <sadmac2> Keybuk: and if so, what replaces the wait on just one process mechanic? it doesn't make much sense for this case
[14:36] <sadmac2> but waiting on a few specific ones might
[14:37] <Keybuk> I figured you'd  use something like the waitid() syntax
[14:37] <Keybuk> waitfd (P_PID, pid, 0)
[14:38] <Keybuk> waitfd (P_ALL, 0, WEXITED | WSTOPPED)
[14:38] <Keybuk> type thing
[14:38] <Keybuk> but then I'm about the only person in the world who even knows about waitid() :p
[14:38] <sadmac2> Keybuk: yes, but say I want to wait on pid 3, 4, and 7, but not 5,6,whatever else
[14:41] <Keybuk> fd = waitfd (-1, P_PID, 6, WEXITED);
[14:41] <Keybuk> err
[14:41] <Keybuk> fd = waitfd (-1, P_PID, 3, WEXITED);
[14:41] <Keybuk> waitfd (fd, P_PID, 4, WEXITED);
[14:41] <Keybuk> waitfd (fd, P_PID, 7, WEXITED);
[14:41] <Keybuk> ?
[14:41] <Keybuk> signalfd-style?
[14:41] <sadmac2> Keybuk: if that's ok with everyone
[14:42] <sadmac2> Keybuk: right now it has waitpid's signature
[14:43] <Keybuk> I don't really like the whole "read an int and figure it out" type approach
[14:43] <Keybuk> that int is squashed from a siginfo_t-style struct in the first place
[14:43] <Keybuk> why not just read that struct?
[14:44] <sadmac2> Keybuk: I didn't use waitid because it doesn't return a different status if it errors out due to WNOHANG, so you have to zero the return struct and then test
[14:44] <sadmac2> Keybuk: and I need to check this from /inside/ the kernel in places.
[14:44] <sadmac2> Keybuk: but I think all of this was in the name of not having to add crap to exit.c, and I think I've had to do that already anyway
[14:46] <sadmac2> there goes my laptop
[14:46] <sadmac2> IRC > Nagios
[14:48] <Keybuk> sadmac2: err, isn't the point that read() returns you that status now ? :P
[14:48] <sadmac2> Keybuk: poll() was the issue
[14:48] <Keybuk> you don't *have* a WNOHANG flag with waitfd
[14:48] <Keybuk> instead you make the socket blocking/non-blocking
[14:48] <Keybuk> and read() returns EAGAIN
[14:48] <sadmac2> Keybuk: I use WNOHANG for poll
[14:49] <Keybuk> why?
[14:49] <sadmac2> Keybuk: check if something exited with WNOHANG+WNOWAIT. If it didn't, poll_wait, if it did, return
[14:52] <Keybuk> oh, I see
[15:10] <sadmac2> Keybuk: you do have a WNOHANG flag with waitfd
[15:10] <sadmac2> Keybuk: WNOHANG == O_NONBLOCK
[15:11] <sadmac2> I've allowed it, and its cheap enough that I'm going to keep on allowing it