On Fri, Nov 18, 2005 at 11:09:14AM -0800, Zac Medico wrote:
> Brian Harring wrote:
> 
> >The modification is pretty straight forward offhand; the notable 
> >difference this time around is rather then extending portage_exec to 
> >have the capability to 'spawn' python funcs (something I always found 
> >ugly), this handles the fork itself.
> 
> This patch seems to work well for me.  I suggest that we add some sort of 
> logging ability so that possible fetch problems will be easier to diagnose.
Note that due to how it's implemented, this does two rounds of 
verification- it'll actually do *two* rounds of fetching too, if 
things go awry in the backgrounded thread.

Logging info is possible, but outputting to the term is nasty- need to 
basically have a message interface (imo) to dump it sanely, rather 
then dumping messages from the background fetcher whenever they 
arrive.  Yes python locks print on it's own, but we also have a lot 
of sys.stdout abuse in use.

Personally?  Screw background logging.  If it fails in the background 
fetcher, it'll rear it's head in the foreground giving immediate display.

If you try to go through and integrate some type of output to the 
term for the background fetcher, you're going to have to do a *lot* of 
arg passing into and out of digest/fetcher to make it remain silent.

I did this in ebd, and it was _not_ a simple patch.  Cost outweighs 
the gain imo (hence the massively simplified patch for stable).

Could keep the old stderr fd around, and write to it when a fetch has 
failed I spose, but again, don't think it's worth it.
~harring