[issue11382] some posix module functions unnecessarily release the GIL

2011-04-23 Thread Antoine Pitrou
Antoine Pitrou added the comment: Sorry for the delay, I had forgotten about this issue. Thank you for the patch! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker __

[issue11382] some posix module functions unnecessarily release the GIL

2011-04-23 Thread Roundup Robot
Roundup Robot added the comment: New changeset eb7297fd5840 by Antoine Pitrou in branch 'default': Issue #11382: Trivial system calls, such as dup() or pipe(), needn't http://hg.python.org/cpython/rev/eb7297fd5840 -- nosy: +python-dev ___ Python trac

[issue11382] some posix module functions unnecessarily release the GIL

2011-04-21 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: Is there anything I can do to help this move forward ? -- ___ Python tracker ___ ___ Pytho

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-04 Thread Terry J. Reedy
Changes by Terry J. Reedy : -- type: -> performance versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: Attached is a patch removing useless calls to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS for several posix functions. It's straigthforward, but since I only have Linux boxes, I couldn't test it under Windows. -- keywords: +patch Added file: ht

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: 2011/3/3 Antoine Pitrou : > > Antoine Pitrou added the comment: > >> Just to be clear, I'm not at all criticizing the current GIL >> implementation, there's been a great work done on it. >> I'm just saying that releasing and re-acquiring the GIL around

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Antoine Pitrou
Antoine Pitrou added the comment: > Just to be clear, I'm not at all criticizing the current GIL > implementation, there's been a great work done on it. > I'm just saying that releasing and re-acquiring the GIL around fast > syscalls is probaly not a good idea. If these syscalls aren't likely t

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: > Do you want to propose a patch? Sure, if removing those calls to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS seems reasonable (I might haved missed something obvious). Just to be clear, I'm not at all criticizing the current GIL implementation, the

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Antoine Pitrou
Antoine Pitrou added the comment: > Well, those are contrived examples showing the effect of the convoy > effect induced by those unneeded GIL release/acquire: releasing and > re-acquiring the GIL comes with a cost (e.g. under Linux, futex are > really fast in the uncontended case since handled

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: Well, those are contrived examples showing the effect of the convoy effect induced by those unneeded GIL release/acquire: releasing and re-acquiring the GIL comes with a cost (e.g. under Linux, futex are really fast in the uncontended case since hand

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: What are you trying to achieve? Do you have loops which contain no other syscall than os.dup2()? -- ___ Python tracker ___ _

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: I didn't even know that Windows had such calls. But anyway, if we start releasing the GIL around each malloc call, then it's going to get really complicated: static PyObject * posix_geteuid(PyObject *self, PyObject *noargs) { return PyLong_Fro

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: On Windows at least, these functions call malloc() and DuplicateHandle(). -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Eric Smith
Changes by Eric Smith : -- components: +Interpreter Core nosy: +eric.smith, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing

[issue11382] some posix module functions unnecessarily release the GIL

2011-03-03 Thread Charles-Francois Natali
New submission from Charles-Francois Natali : Some posix module functions unnecessarily release the GIL. For example, posix_dup, posix_dup2 and posix_pipe all release the GIL, but those are non-blocking syscalls (the don't imply any I/O, only modifying the process file descriptors table). This

[issue11382] some posix module functions

2011-03-03 Thread Charles-Francois Natali
Changes by Charles-Francois Natali : -- nosy: neologix priority: normal severity: normal status: open title: some posix module functions ___ Python tracker ___ __