Re: [Duplicity-talk] idea on gpg zombies

[edgar . soldin]

On 28.06.2011 23:39, Kenneth Loafman wrote:
> We make it in a thread so it can proceed.  

proceed for what. we can as well wait for gpg to finish up and go on with the 
next file. can't we? 

>At the end of the waitpid all of the closed file handles are harvested (except 
>on a Mac) and the task is allowed to close.  

i can't see code that harvests it, so you speak of waitpid doing that on it's 
own, do you?
if so:
why not close them manually before calling waitpid? can't hurt, might help?

>Without the threading, you get a pile of gpg processes that don't go away 
>until the very end.  

well e.g. ncftp calls don't stick until the end and are done totally without 
threading. simple system calls.

>The parent has to issue the waitpid to get this to happen, and on its own, 
>duplicity waits until the very end of the iteration to take care of this task.

i already understood what waitpid should accomplish. sadly it does not under 
certain, not well known, circumstances. i try to think of solutions here, or at 
least approaches that might resolve this issue once and for all.

ede/duply.net

> 
> ...Ken
> 
> On Tue, Jun 28, 2011 at 3:38 PM, <address@hidden <mailto:address@hidden>> 
> wrote:
> 
>     i just read a little about the process closing with waitpid in python. i 
> also read through GnuPGInterface.py and gpg.py.
> 
>     if i understand correctly this gpg.py opens the process and deals as a 
> filehandler which pipes data in or out of the process. on close it is 
> supposed to call the wait method, which actually calls waitpid, which should 
> theoretically end the process thread.
> 
>     two things occure to me.
> 
>     thing one:
>     i miss an explicit closing of pipes and file handlers here. i could 
> imagine that open fh/pipes could leave a thread hanging. a loop closing all 
> those in wait() might help here.
> 
>     thing two:
>     the other is, why do we actually thread this? is duplicity multithreaded 
> at all? don't we actually write/read one file after the other?
>     notable exception maybe the asynchronous mode. but that's uploading vs 
> file creation in parallel so no gpg threading needed here.
>     crazy idea. let's tell GnuPGInterface.py to ignore threading, i see it is 
> built with a fallback if threading returns a 0 pid and simply stays in the 
> parent process.
> 
>     just my two things,
>     regards ede/duply.net <http://duply.net>
> 
>     _______________________________________________
>     Duplicity-talk mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> 
> 
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk