Re: Another lintian release for squeeze?
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?
>
> 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.
>
> Lintian::Command::Simple looks like a good idea to me, but please don't
> call the system() function exec(). I will keep expecting it to be, well,
> exec. :)
Heh, yeah. Those were terribly-chosen names but I lacked imagination that
day :)
What do you suggest to use as names instead of fork() and exec()? what about
the interface to reap jobs?
Maybe wait(), when passed a hash ref, should return the value of the hash
member that was reaped, when called in scalar context. In array context it
should probably return the key, value pair.
It seems that the only way to achieve what I want requires wait() to:
a) call CORE::wait() to get the pid and $? of the reaped process.
b) call $cmd->pid() for every member of the hash it was passed to see which
of the processes was the one that finished. Needs to be done this way
because we could otherwise end up reaping more jobs, if waitpid($pid,
WNOHANG) was used.
c) tell the $cmd object what the return status was. This requires a getter
and a setter to be added to the OO interface. The former should probably
refuse to set the return status if $self->wait() doesn't return -1.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: