By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,551 Members | 1,127 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,551 IT Pros & Developers. It's quick & easy.

Is my thread safe from premature garbage collection?

P: n/a
Hello all,

I'm aware that in Python an object is cleared for garbage collection as
soon as the last reference to it disappears. Normally this is fine.
However, in my current project I'm creating a bunch of threads which
are supposed to run until they've completed their run() method, and I'm
worried that if I do not keep references to these thread objects
around, the GC might happily delete them (and thereby kill my thread
routines maybe?) while they're not done yet. Is this fear justified? Or
is the Python GC smart enough to leave thread objects alone until their
run() methods have finished?

If not, I do have a workaround, but it is a bit clumsy IMO. Basically I
would just keep a list into which each thread object enters a reference
to itself on creation. This way I'd ensure that I have a reference to
the thread to prevent the GC from killing it. Then, when a thread is
about to finish its run() method, the thread finds and removes that
reference to itself from my list of thread references.

Anyway, if anyone could make a definite statement on whether threads
are safe from unwanted garbage collection, that'd be really great.
Thanks in advance for any helpful replies!

Cheers,

antred

Sep 1 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Nu****@gmx.net a écrit :
Anyway, if anyone could make a definite statement on whether threads
are safe from unwanted garbage collection, that'd be really great.
Thanks in advance for any helpful replies!


As far as I know, the threading module keeps a reference around for each
thread, until its target method returns. I frequently use a thread
without keeping any reference to it and never encountered any problem.
Sep 1 '05 #2

P: n/a
Nu****@gmx.net wrote:
Hello all,

I'm aware that in Python an object is cleared for garbage collection as
soon as the last reference to it disappears. Normally this is fine.
However, in my current project I'm creating a bunch of threads which
are supposed to run until they've completed their run() method, and I'm
worried that if I do not keep references to these thread objects
around, the GC might happily delete them (and thereby kill my thread
routines maybe?) while they're not done yet. Is this fear justified? Or
is the Python GC smart enough to leave thread objects alone until their
run() methods have finished?

If not, I do have a workaround, but it is a bit clumsy IMO. Basically I
would just keep a list into which each thread object enters a reference
to itself on creation. This way I'd ensure that I have a reference to
the thread to prevent the GC from killing it. Then, when a thread is
about to finish its run() method, the thread finds and removes that
reference to itself from my list of thread references.

Anyway, if anyone could make a definite statement on whether threads
are safe from unwanted garbage collection, that'd be really great.
Thanks in advance for any helpful replies!


The threading module does already take care of keeping references to all
running threads, so there's no need to do it yourself and your threads are
safe from being garbage collected.

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/
Sep 1 '05 #3

P: n/a
Splendid! =) Thanks guys!

Sep 1 '05 #4

P: n/a
In article <df**********@online.de>, Benjamin Niemann <pi**@odahoda.de> wrote:
Nu****@gmx.net wrote:
However, in my current project I'm creating a bunch of threads which
are supposed to run until they've completed their run() method, and I'm
worried that if I do not keep references to these thread objects
around, the GC might happily delete them (and thereby kill my thread
routines maybe?) while they're not done yet. Is this fear justified?

The threading module does already take care of keeping references to all
running threads,


The implementation of threading.enumerate() would be entertaining if it
didn't.

Quite apart from which, I presume the OP's run() method looks something
like:
class MyThread(threading.Thread):
def run(self):
...
So what is self if not a reference to the Thread object which is kept
around until run() has completed?

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
Sep 1 '05 #5

P: n/a
Sion Arrowsmith wrote:
In article <df**********@online.de>, Benjamin Niemann <pi**@odahoda.de>
wrote:
Nu****@gmx.net wrote:
However, in my current project I'm creating a bunch of threads which
are supposed to run until they've completed their run() method, and I'm
worried that if I do not keep references to these thread objects
around, the GC might happily delete them (and thereby kill my thread
routines maybe?) while they're not done yet. Is this fear justified?

The threading module does already take care of keeping references to all
running threads,


The implementation of threading.enumerate() would be entertaining if it
didn't.

Quite apart from which, I presume the OP's run() method looks something
like:
class MyThread(threading.Thread):
def run(self):
...
So what is self if not a reference to the Thread object which is kept
around until run() has completed?


This was just too obvious;) Looking at the sourcecode of the threading
module and discovering the 'limbo' dict, where every thread stores a
reference to itself, was certainly more entertaining.

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/
Sep 1 '05 #6

P: n/a
Good point there. Sorry, I should have thought of that myself really,
but well, I guess I'm having my senior moments a bit early. :P

Sep 8 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.