setDaemon problem.

[Ramashish Baranwal]

Hi,

I am facing an issue in daemonizing a thread using setDaemon method.
Here is my code-

import time
from threading import Thread

class MThread(Thread):
def run(self):
f = open('/tmp/t.log', 'w')
for i in range(10):
f.write('Iteration %d\n' % i)
time.sleep(1)
f.close()

if __name__ == "__main__":
t = MThread()
t.setDaemon(True)
print 'Starting thread'
t.start()

The scripts runs all fine, but nothing gets logged to "/tmp/t.log".
However when I run the same script without setting thread as daemon
(no call to t.setDaemon), everything works fine.

Am I missing anything?

Thanks in advance,
Ram

[Diez B. Roggisch]

Ramashish Baranwal schrieb:

Hi,

I am facing an issue in daemonizing a thread using setDaemon method.
Here is my code-

import time
from threading import Thread

class MThread(Thread):
def run(self):
f = open('/tmp/t.log', 'w')
for i in range(10):
f.write('Iteration %d\n' % i)
time.sleep(1)
f.close()

if __name__ == "__main__":
t = MThread()
t.setDaemon(True)
print 'Starting thread'
t.start()

The scripts runs all fine, but nothing gets logged to "/tmp/t.log".
However when I run the same script without setting thread as daemon
(no call to t.setDaemon), everything works fine.

Am I missing anything?

Yes. You miss the documentation of setDaemon. It is _not_ a
PROCESS-daemonization recipe - which you can get here:

http://aspn.activestate.com/ASPN/Coo...n/Recipe/66012

Instead, it means that the thread started is considered not to be worth
waiting for when the main thread exits. Which it does immediately in
your code, resulting in nothing written in the logfile.

I think the name setDaemon is somewhat unfortunate.
Diez

[Ramashish Baranwal]

Hi,

>

I am facing an issue in daemonizing a thread using setDaemon method.
Here is my code-

import time
from threading import Thread

class MThread(Thread):
def run(self):
f = open('/tmp/t.log', 'w')
for i in range(10):
f.write('Iteration %d\n' % i)
time.sleep(1)
f.close()

if __name__ == "__main__":
t = MThread()
t.setDaemon(True)
print 'Starting thread'
t.start()

The scripts runs all fine, but nothing gets logged to "/tmp/t.log".
However when I run the same script without setting thread as daemon
(no call to t.setDaemon), everything works fine.

Am I missing anything?

Yes. You miss the documentation of setDaemon. It is _not_ a
PROCESS-daemonization recipe - which you can get here:

http://aspn.activestate.com/ASPN/Coo...n/Recipe/66012

Instead, it means that the thread started is considered not to be worth
waiting for when the main thread exits. Which it does immediately in
your code, resulting in nothing written in the logfile.

I think the name setDaemon is somewhat unfortunate.

Thanks Diez,

I was also wondering about "daemonizing" a thread, but I interpreted
that it would daemonize the process which it didn't. I think setDaemon
should be renamed to setDetached or something similar.

Ram

[Richard Brodie]

"Ramashish Baranwal" <ra*************@gmail.comwrote in message
news:11**********************@d57g2000hsg.googlegr oups.com...

I was also wondering about "daemonizing" a thread, but I interpreted
that it would daemonize the process which it didn't. I think setDaemon
should be renamed to setDetached or something similar.

Neither is particularly intuitive; it just depends whether you are more
familiar with the Posix terminology or the Java one. I personally prefer
detached but there is little chance of a name change now.

[Michael Hoffman]

Richard Brodie wrote:

"Ramashish Baranwal" <ra*************@gmail.comwrote in message
news:11**********************@d57g2000hsg.googlegr oups.com...

>I was also wondering about "daemonizing" a thread, but I interpreted
that it would daemonize the process which it didn't. I think setDaemon
should be renamed to setDetached or something similar.

Neither is particularly intuitive; it just depends whether you are more
familiar with the Posix terminology or the Java one. I personally prefer
detached but there is little chance of a name change now.

Why not? That's what Python 3.0 is for.
--
Michael Hoffman

[Richard Brodie]

"Michael Hoffman" <ca*******@mh391.invalidwrote in message
news:f0**********@gemini.csx.cam.ac.uk...

>Neither is particularly intuitive; it just depends whether you are more
familiar with the Posix terminology or the Java one. I personally prefer
detached but there is little chance of a name change now.

Why not? That's what Python 3.0 is for.

I think you need a better reason than: "it's mildly confusing to people, if
they don't read the manual" for an API change; but that's just my opinion.

[Michael Hoffman]

Richard Brodie wrote:

"Michael Hoffman" <ca*******@mh391.invalidwrote in message
news:f0**********@gemini.csx.cam.ac.uk...

>>Neither is particularly intuitive; it just depends whether you are more
familiar with the Posix terminology or the Java one. I personally prefer
detached but there is little chance of a name change now.

Why not? That's what Python 3.0 is for.

I think you need a better reason than: "it's mildly confusing to people, if
they don't read the manual" for an API change; but that's just my opinion.

One of the goals of Python 3.0 is to clean up previous warts in the
language, and there will be a number of API changes. And one of the good
things about Python in general is that things frequently can be
understood without reading a manual. I think anything to aid this should
be encouraged.
--
Michael Hoffman