Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #3401
| Date | 2011-04-17 16:15 +0100 |
|---|---|
| From | Ian <hobson42@gmail.com> |
| Subject | Re: Questions about GIL and web services from a n00b |
| References | <4DA8734C.1080706@WindsorCircle.com> <BANLkTikP03hkFPFz6diSpDgE8hQ5ZCWE2A@mail.gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.463.1303053332.9059.python-list@python.org> (permalink) |
On 15/04/2011 20:17, Dan Stromberg wrote: > On Fri, Apr 15, 2011 at 9:33 AM, Chris H > <chris.humphres@windsorcircle.com> wrote: > >> 1. Are you sure you want to use python because threading is not good due to >> the Global Lock (GIL)? Is this really an issue for multi-threaded web >> services as seems to be indicated by the articles from a Google search? If >> not, how do you avoid this issue in a multi-threaded process to take >> advantage of all the CPU cores available? > Concurrency in Python is a largish topic. > > It's true that CPython's multithreading is poor. In fact, running a > multithreaded CPython application on n vs 2n cores can actually take > more time on the 2n cores. > > However: > 1) In Jython, and likely IronPython, threading is good. The load times of Iron Python are ssslllooooowwwww! (My tests showed startup times 4 to 6 times that of cpython on the same kit). > 3) There's something called "stackless" and (similar to stackless) > "greenlets". While stackless allows you to use thousands of threads > comfortably, it's still pretty single-core. It's essentially a fork > of CPython, and is being made a part of PyPy. I believe greenlets are > an attempt to bring what's good about stackless to CPython, in the > form of a C extension module. Greenlets are green threads - cooperative switching all in one system thread and therefore one core. Very lightweight. > 4) I've heard that in CPython 3.2, the GIL is less troublesome, though > I've not yet heard in what way. Multiple threads still cannot run at the same time, however, if one thread runs too long without a context switch, it relinquishes control and forces another thread to run. This stops a low priority thread on one core, locking out a high-priority thread on another. That this was happening is why 2 cores can be slower than one. (The overhead of starting the second thread, finding it can't get the GIL and closing down again). > 5) Even in CPython, I/O-bound processes are not slowed significantly > by the GIL. It's really CPU-bound processes that are. Its ONLY when you have two or more CPU bound threads that you may have issues. Regards Ian
Back to comp.lang.python | Previous | Next — Next in thread | Find similar
Re: Questions about GIL and web services from a n00b Ian <hobson42@gmail.com> - 2011-04-17 16:15 +0100 Re: Questions about GIL and web services from a n00b sturlamolden <sturlamolden@yahoo.no> - 2011-04-17 08:49 -0700
csiph-web