Oren Held o...@held.org.il added the comment:
Just adding some info:
This bug is not Solaris-specific; I reproduced it on HP-UX 11.31.
On Python 2.6.4, thread_test.py fails with the same RunTime error exception.
On Python 2.6.6, it passes and things look good.
--
nosy: +Oren_Held
Gregory P. Smith g...@krypto.org added the comment:
Using issue7242-gps01.diff on release26-maint and a freshly downloaded
opensolaris 2009-06 VM test_thread, test_threading and test_subprocess all pass
for me both before -and- after the patch. Nor does the original thread_test.py
cause the
Greg Jednaszewski jednaszew...@gmail.com added the comment:
The problem only seems to appear on Solaris 9 and earlier. I'll try to test
the updated patch tonight or tomorrow and let you know what I find.
--
___
Python tracker rep...@bugs.python.org
Gregory P. Smith g...@krypto.org added the comment:
If you have a chance tonight that'd be awesome. I'd love to get this in before
2.6.5rc1 (being cut tomorrow) but as its platform specific (and a pretty-old
platform at that) its not worth holding up the release.
--
Greg Jednaszewski jednaszew...@gmail.com added the comment:
I tested the updated patch, and the new unit test passes on my Sol 8 sparc, but
the test_threading test still hangs on my system. However, given that the test
is skipped on several platforms and it does work on more relevant versions
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
There's a bundled unittest in test_httpservers which actually fails if this
patch is not applied.
See the unittest attached. Unfortunatelly RuntimError is raised in the child
process after fork() so I cannot re-raise it to the
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
I've run unittest with both patched and vanilla versions of python 2.6.4 and I
confirm that it fails when it's run by vanilla on solaris 8, but passes on the
patched version.
--
___
Greg Jednaszewski jednaszew...@gmail.com added the comment:
I spent some time working on and testing a unit test as well. It's the same
basic idea as Zsolt Cserna's, but with a slightly different approach. See
7242_unittest.diff. My unittest fails pre-patch and succeeds post-patch.
Dagobert Michelsen d...@opencsw.org added the comment:
I verified patch_2.diff on Solaris 10 w/SOS11 and it actually resolves a number
of issues I had with Mercurial.
--
nosy: +dagobert Michelsen
___
Python tracker rep...@bugs.python.org
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
Ok, here's the new patch. I've removed the #ifdef-#endif lines. It passed the
test thread_test.py on linux (and as well on solaris).
--
Added file: http://bugs.python.org/file16011/patch_2.diff
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
I compile it with -lpthread.
os.fork1() was not available by default, I enabled it by removing two lines
from posixmodule.c (it seems it's only enabled when #if defined(__USLC__)
defined(__SCO_VERSION__) is true).
With os.fork1()
Martin v. Löwis mar...@v.loewis.de added the comment:
In my patch I wanted to reduce the effect on systems where forking in
thread is working (eg. linux), that's the reason why I added
(defined (__SVR4) defined (__sun).
I think that's inappropriate, please change that.
--
Martin v. Löwis mar...@v.loewis.de added the comment:
One relevant difference may be the change to the fork semantics in Solaris 10:
fork() now means the same as fork1(). Before, fork() meant the same as
forkall(), unless the applications was linked with -lpthread, in which case
fork() also
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7242
___
___
Python-bugs-list
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
Additional info:
I've tested it on solaris 10 / sparc 32-bit, and my test script runs
fine on that.
Based on my test it seems that this bug does not affect solaris 10.
--
___
Python
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
I've tested it only on solaris 8, 32-bit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7242
___
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
solaris 10 x86, 32-bit, sun-studio 11 is ok (in this case the parent's
thread has thread_id=2 and the child inherits this id)
solaris 8 sparc4, 32-bit, sun-studio 11 is not working
So it seems it's independent from sun-cc but
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
I've attached a patch which seems to fix this issue. It sets
import_lock_thread to the current thread id after forking in the child
process, but still I'm not quite sure that it's the correct way of
solving this issue.
--
Gregory P. Smith g...@krypto.org added the comment:
This only appears to happen on Solaris. What version of Solaris are you
using? (i doubt that matters, i expect it happens on all versions)
I haven't look closely enough at the code yet, but reinitializing the
import lock in the child
New submission from Zsolt Cserna zsolt.cse...@morganstanley.com:
Python 2.6.4 (r264:75706, Oct 29 2009, 12:00:12) [C] on sunos5
On my sunos5 system if I call os.fork() in a thread created by
thread.start_new_thread(), it raises RuntimeError with the message 'not
holding the import lock'. It's a
Antoine Pitrou pit...@free.fr added the comment:
Well, there has been no such change between 2.6.3 and 2.6.4.
--
nosy: +gregory.p.smith, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7242
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment:
Sorry, the working version is not 2.6.3 (I mistyped the version), it's
2.6.1 (I've no info about 2.6.2).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7242
22 matches
Mail list logo
