[concurrency] Reworking the GIL

Antoine Pitrou solipsis at pitrou.net
Sun Nov 1 18:50:31 CET 2009

Le dimanche 01 novembre 2009 à 17:09 +0000, Michael Sparks a écrit :
> Can you explain what effect you're aiming to achieve with this change?

As the message on python-dev says: make switching latencies more
predictable (rather than wildly varying), and reduce the overhead of the
GIL itself (in terms of spurious system calls, for example, and
therefore of wasted CPU time with multiple threads).

> The reason I'm asking is because using kamaelia[2] it should be
> possible to craft a bunch of useful test cases or benchmarks  - as
> long as I know what I'm supposed to be testing :-)

Well, it would be nice if you had an existing multithreaded py3k
workload so as to test it with the newgil branch.

(as far as benchmarks go, I've written ccbench which tries to test the
things I was interested in when starting this experiment)

> Similarly the generator scheduler sleeps in a thread - either
> foreground or background - until something needs running) Similar
> points go for GUI code etc as well. As a result having mixed workloads
> is common, so if this reworking should have a benefit, we should be
> able to practically test for in with kamaelia :-)

Well if you are somehow unsatisfied with long (GUI, IO, etc.) latencies
in your workload perhaps the new GIL will improve things. If you are
satisfied with the current GIL, however, I think it's unlikely you'll
notice any difference :-)

> [1] I find python.org mailing lists a real pain in the neck because
> the mail server throws away perfectly valid mails from my mail server,
> so I have to really want to send something if I want to send anything
> - because it means I end up having to use google's web gmail interface

You should contact the postmaster or mail admin at python.org, IMO.
(I don't like the Google stuff either, and I tend to run away from
everything Google groups)



More information about the concurrency-sig mailing list