Russ Allbery <[email protected]> writes: > Looking at frontend/lintian modifications, we really need a > restructuring of how Lintian::Command is used when running things in > parallel. IPC::Run is really a bad fit for this since you can't get the > PID file out of IPC::Run, and what we really want is something like: > > # start a bunch of children storing PIDs in %children > while (%children) { > my $child = wait; > # finish up with PID $child > delete $children{$child}; > } > > which you can't do with IPC::Run. But we're not using any of the cool > facilities of IPC::Run when running collection scripts anyway, so I > would just replace all that with fork and exec, but probably stuff the > code into Lintian::Command, giving it some functions to handle sets of > children that complete asynchronously like this. Maybe using some > sort of callback facility?
Thinking about this some more, I think I want Lintian::Command::Set, with an API something like: =item new() Constructor. =item start(NAME, COMMAND[, ARG ...]) Start COMMAND in the background and add it to the set. =item wait() Wait for a child to exit and return, in a list, the corresponding NAME of the set member and the exit status. Removes the completed child from the running set. =item done() Returns true if the running set is empty, false otherwise. =item wait_all() Wait for all remaining children to finish. Returns a list of tuples of names and exit statuses for all completed children. =cut That would make it trivial to do something like the above pseudo-code and would be a lot nicer than using IPC::Run for the same thing. I don't think I'm missing any facility that we'd need. This would obviously only be usable with stuff we want to run in the background where we don't have to do any plumbing, but that's exactly the case for the collection scripts. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
