Issue 6800: os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application (original) (raw)
Created on 2009-08-29 03:19 by rnk, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (6)
Author: Reid Kleckner (rnk) 
Date: 2009-08-29 03:19
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:
Traceback (most recent call last): File "daemon_exec.py", line 16, in main() File "daemon_exec.py", line 13, in main os.execl('echo', 'hello world') File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py", line 312, in execl execv(file, args) OSError: [Errno 45] Operation not supported
And on my Linux box:
hello world
Here's a similar bug that OCaml had to deal with: http://caml.inria.fr/mantis/view.php?id=4666
I think it's reasonable for Python to declare this to be a limitation of the OS, but considering that the other thread could be a daemon thread that the user doesn't really care about, I think it would be reasonable for Python to kill the other threads in the process before execing. That's what happens on Linux, anyway.
I ran into this problem while trying to add a persistent background compilation thread to unladen swallow, and wondered if having any other threads would trigger the same exception.
It's tempting to just write this off, but I figured it should be documented or left open as a low priority defect.
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2009-08-29 04:57
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 in os.execv because it is unclear if that is a save thing to do (what if the system starts a number of threads in the background, killing one of them might crash your application before we get around to killing another one).
Author: Reid Kleckner (rnk)
Date: 2009-08-29 05:13
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 swallow, we'll bring down our background thread by another means. Unfortunately, there's no way to join pythreads, so I have to add a hack that just retries the execv call if errno == EOPNOTSUPP with an eventual timeout.
Author: Gregory P. Smith (gregory.p.smith) *
Date: 2009-08-29 07:15
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 is an OS problem.
Most macosx users will only ever use the python that apple feeds them so I don't see what point working around this in Python would have given that snow leopard (10.6) appears to fix this.
Feel free to contribute patches with appropriate autoconf magic and ifdefs surrounding them if you feel otherwise.
Author: Ross Lagerwall (rosslagerwall)
Date: 2011-01-03 13:06
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 like the latest versions of those platforms have overcome this limitation anyway.
Author: Antoine Pitrou (pitrou) *
Date: 2011-01-03 14:05
Agreed, not a Python bug.
History
Date
User
Action
Args
2022-04-11 14:56:52
admin
set
github: 51049
2011-01-03 14:05:07
pitrou
set
status: open -> closed
nosy: + pitrou
messages: +
resolution: rejected
2011-01-03 13:06:25
rosslagerwall
set
nosy: + rosslagerwall
messages: +
2009-12-08 16:43:05
ronaldoussoren
set
assignee: ronaldoussoren ->
2009-08-29 07:16:09
gregory.p.smith
set
priority: low
2009-08-29 07:15:39
gregory.p.smith
set
nosy: + gregory.p.smith
messages: +
2009-08-29 05:13:32
rnk
set
messages: +
2009-08-29 04:57:52
ronaldoussoren
set
messages: +
2009-08-29 03:19:46
rnk
create