[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Duplicity-talk] idea on gpg zombies
From: |
edgar . soldin |
Subject: |
[Duplicity-talk] idea on gpg zombies |
Date: |
Tue, 28 Jun 2011 22:38:33 +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 |
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
- [Duplicity-talk] idea on gpg zombies,
edgar . soldin <=