duplicity-talk
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]