Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: False
assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2
conversion or agent startup)"):
> You're just talking about adding this one test, right?
That's my understanding.
> It seems to me like this shouldn't be necessary, since i'd have thought
> the child channel (chan_9 in your example) receiving eof would make the
> main thread wake back up.
AIUI this is supposed to happen, indeed. So the timer tick is hiding
the race, by having gpg-agent wake up occasionally anyway and become
unstuck.
> can you explain why that wouldn't be the case? is there some way to
> cause the main thread to trigger a loop when the child channel closes?
There's interrupt_main_thread_loop. But it is not called. I think it
should be called when active_connections becomes zero.
That's what my patch 4/4 does, and that patch fixes most of the
problem for me.
There is a remaining race with much lower probability. I think It
happens when an incoming connection arrives just as gpg-agent is
finally deciding to actually exit. The symptoms are that some gpg
invocation complains about getting EOF from the agent.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
