[master 0/4] Poke at iutil.execReadlines

David Shea dshea at redhat.com
Tue Aug 12 13:36:45 UTC 2014


On 08/12/2014 02:59 AM, Vratislav Podzimek wrote:
> On Fri, 2014-08-08 at 15:32 -0400, David Shea wrote:
>> Maybe this is why anaconda-yum gets stuck sometimes? I don't know. I just
>> figure a thread can't starve if there ain't no thread, so this gets rid of
>> a thread and adds some tests to make sure I didn't break things too badly.
> I still don't understand the reason for removing the thread. I think it
> is better to just pull out the output of the process and let it
> terminate ASAP even if our processing takes longer. Is it only because
> it's simpler and easier to debug or python's problematic signal
> handling?

Well, from the other side of things, I don't understand what the thread 
and queue gains us. There's already a buffer between the parent and the 
child inherent to using pipes, and if we want we can use (or relative to 
this patch, go back to using, and setting bufsize back to 1 probably 
wouldn't be the worst idea) the additional buffer within the Popen 
object. From the standpoint of the child, unless it fills that kernel 
buffer (4k? 8k? one of those I think) and is blocking on write, from 
it's point of view it's done with the output. Using an additional thread 
doesn't get it out of the child any faster, it just copies it do a 
different buffer faster.

> Which brings me to another question -- what happens if our code doesn't
> read all the output from the process? Does it even terminate? We should
> have a test case for that as well as I think it is a completely valid,
> useful and used usecase (use, use, use :)).

This is kind of one of those grey areas, but either the output will be 
hanging out in kernel buffer land and we read it without any problems, 
or the read fails with EPIPE and that gets translated into an OSError. 
Setting the bufsize back to 1 would be a good idea in light of this to 
avoid problems reading the last line before the process exits.

As far as the process terminating, unless the write is blocked, which is 
unlikely, then yes, of course it does.

>
> The patches 1/4-3/4 look good to me with the one minor comment on 2/4.
>



More information about the anaconda-patches mailing list