Hi, When you say this "C extensions (usually) release the GIL when they don't call into any Python code" do you talk about this macros ?
Py_BEGIN_ALLOW_THREADS Py_END_ALLOW_THREADS On Wed, Jun 11, 2008 at 3:52 AM, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Mon, 09 Jun 2008 15:26:09 -0300, Pau Freixes <[EMAIL PROTECTED]> > escribió: > > Surly this is a recurring theme into python dev world, but I need your >> help >> for confirm if the follow image it's really >> >> http://www.milnou.net/~pfreixes/img/cpu_usage_gil_problem.png<http://www.milnou.net/%7Epfreixes/img/cpu_usage_gil_problem.png> >> <http://www.milnou.net/%7Epfreixes/img/cpu_usage_gil_problem.png> >> >> I'm writing a brief article for my blog and I need to make sure about the >> current problem with GIL and multi core environments, this picture try to >> explain with images the problem for scheduling multiple threads running >> python code of same interpreter into multiple cpu cores. Can anyone >> confirm >> to me this picture ? >> > > Yes, if both threads are executing pure Python code, they can't run > simultaneously. > > Note that: > - C extensions (usually) release the GIL when they don't call into any > Python code > - The interpreter also releases the GIL before any I/O operation > If the process is I/O bound then the GIL is not so important, and if it's > CPU bound you may benefit from reimplementing the critical parts in C (by > example, using NumPy for a number-crunching process). Another alternative is > to use multiple processes with some form of IPC instead of multiple threads. > These are the usual arguments against "fear of GIL". You should consider > your specific application to see if the GIL is actually a problem in your > case or not. > > -- > Gabriel Genellina > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Pau Freixes Linux GNU/User
-- http://mail.python.org/mailman/listinfo/python-list
