Russ Allbery wrote: > Raphael Geissert writes: > >> I'm attaching both changes. Comments? suggestions? > >> 0007 includes the first set of changes of Lintian::Command::Simple. In >> the .t file I was trying to decide the best way to handle multiple jobs >> while still being able to recognise which one is reaped. > > Is there any way that we can fix the output handling so that at least it > won't intersperse output from multiple threads? Making failures basically > unreadable is unappealing, and I assume that's the possible result. Can > we use some sort of locking method so that only one thread is printing > stuff to the terminal at a time and finishes dumping its stuff, including > its possible diff, before letting someone else go?
I don't think it's possible to lock the file descriptors. A possible solution is to open two file descriptors for every thread, replacing their STDOUT/STDERR. Another thread would be started and would take care of multiplexing with select(). Probably using IO::Multiplex. > > In parallel mode, we should stop printing partial status (building, > testing, OK) etc. and just print out the complete line to the point that > we got and then the failure results if any all at once. That will work > better with the output handling. It might still be possible to print that information in the last printable line, a-la prove's -j. Since doing this is going to take some time, is there any objection for merging the initial -j option support to at least make prove run multiple jobs? (i.e. not merging the 'use threads' part.) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
