Ross Lagerwall rosslagerw...@gmail.com added the comment:
I tested this on FreeBSD 8.1 - it outputs 'hello world'.
I think this should be closed - i think the os.exec* functions should mirror
the operating system exec* functions. If the platform has a limitation then so
be it.
And it seems
Antoine Pitrou pit...@free.fr added the comment:
Agreed, not a Python bug.
--
nosy: +pitrou
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6800
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
assignee: ronaldoussoren -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6800
___
___
Changes by Gregory P. Smith g...@krypto.org:
--
priority: - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6800
___
___
Python-bugs-list
Gregory P. Smith g...@krypto.org added the comment:
There is no OS level API to kill threads. Python does not kill threads.
When you exec, your entire process should be replaced by the OS, threads
shouldn't matter they should simply disappear just as the rest of your
process state does.
This
New submission from Reid Kleckner r...@mit.edu:
The test case is attached. On Mac OS X (and presumably FreeBSD, which
has the same behavior) when you try to exec from a process that has any
other threads in it, you get an OSError, Operation not supported.
Here's the output on my MacBook:
Ronald Oussoren ronaldousso...@mac.com added the comment:
The issue with execv seems to be resolved on OSX 10.6, and hence the
problem will go away by itself in the future.
But until OSX 10.5 and earlier have died of this is a valid issue.
My gut feeling is that I'm -1 on killing all threads
Reid Kleckner r...@mit.edu added the comment:
Supposedly this bug also affects FreeBSD, but I can't verify it. I'd
say the problem isn't going away, at least not for that platform, but I
don't feel like it's worth bending over backwards to deal with it either.
As far as it concerns unladen
