Russ Allbery wrote: > Raphael Geissert writes: >> Russ Allbery wrote: > >>> 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. > > Yeah, but you don't need to. You can use a separate variable as mutex > lock.
Sure. The problem is that the output of subcommands is not under the control of the thread and as such it can't lock in case of failure or unexpected writes. > >> 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.) > > Oh, sure, I have no objections to that. I don't really have any > objections to merging the support for parallel tests in general, just > don't want to make it the default until we figure out how to handle the > output. Since by default it defaults to using two jobs, I'm going to hold the other changes for now. 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]
