1 |
On Fri, Nov 18, 2005 at 11:09:14AM -0800, Zac Medico wrote: |
2 |
> Brian Harring wrote: |
3 |
> |
4 |
> >The modification is pretty straight forward offhand; the notable |
5 |
> >difference this time around is rather then extending portage_exec to |
6 |
> >have the capability to 'spawn' python funcs (something I always found |
7 |
> >ugly), this handles the fork itself. |
8 |
> |
9 |
> This patch seems to work well for me. I suggest that we add some sort of |
10 |
> logging ability so that possible fetch problems will be easier to diagnose. |
11 |
Note that due to how it's implemented, this does two rounds of |
12 |
verification- it'll actually do *two* rounds of fetching too, if |
13 |
things go awry in the backgrounded thread. |
14 |
|
15 |
Logging info is possible, but outputting to the term is nasty- need to |
16 |
basically have a message interface (imo) to dump it sanely, rather |
17 |
then dumping messages from the background fetcher whenever they |
18 |
arrive. Yes python locks print on it's own, but we also have a lot |
19 |
of sys.stdout abuse in use. |
20 |
|
21 |
Personally? Screw background logging. If it fails in the background |
22 |
fetcher, it'll rear it's head in the foreground giving immediate display. |
23 |
|
24 |
If you try to go through and integrate some type of output to the |
25 |
term for the background fetcher, you're going to have to do a *lot* of |
26 |
arg passing into and out of digest/fetcher to make it remain silent. |
27 |
|
28 |
I did this in ebd, and it was _not_ a simple patch. Cost outweighs |
29 |
the gain imo (hence the massively simplified patch for stable). |
30 |
|
31 |
Could keep the old stderr fd around, and write to it when a fetch has |
32 |
failed I spose, but again, don't think it's worth it. |
33 |
~harring |