[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] idea on gpg zombies
From: |
edgar . soldin |
Subject: |
Re: [Duplicity-talk] idea on gpg zombies |
Date: |
Tue, 28 Jun 2011 23:56:26 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 |
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