This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients amaury.forgeotdarc, eric.smith, neologix, pitrou
Date 2011-03-03.12:39:11
SpamBayes Score 5.6649924e-08
Marked as misclassified No
Message-id <1299155952.16.0.16875675738.issue11382@psf.upfronthosting.co.za>
In-reply-to
Content
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 in use space but much slower when there's contention), and subverts the OS scheduling policy (forcing the thread to drop/re-acquire the GIL make the thread block after having consumed a small amount of its time slice and increases the context switching rate). I think that releasing and re-acquiring the GIL should only be done around potentially blocking calls.

> Do you have loops which contain no other syscall than os.dup2()?

No, but it's not a reason for penalizing threads that use dup, dup2 or pipe.
History
Date User Action Args
2011-03-03 12:39:12neologixsetrecipients: + neologix, amaury.forgeotdarc, pitrou, eric.smith
2011-03-03 12:39:12neologixsetmessageid: <1299155952.16.0.16875675738.issue11382@psf.upfronthosting.co.za>
2011-03-03 12:39:11neologixlinkissue11382 messages
2011-03-03 12:39:11neologixcreate