David, yes messing about with processor affinities is certainly not nice.
Especially since the issue is cross-platform.
The pthreads api doesn't offer much.  There is pthreadd_setschedparam(), and pthreads_setconcurrency().  Unfortunately I don't have a pthreads machine to test that with.
On windows, one possibility would be to switch to fibers, in the case of a yielding thread.  I don't know if that would change anything, or if the thread-to-fiber and vice versa conversion is lightweight enough to be used dynamically.

Antoine: I'm not familiar with ccbench.  I´ll look into it.   As for my FIFO fix, py3k is trying to do more, namely get rid of the checkinterval. It is most certainly a more complex solution and with it its own set of problems.  The only thing that needs fixing is to add "fairness" to the GIL.

I know that this is coming a bit late for 2.7 and I'm not pushing it as such for 2.7.  But after 2.7 comes 2.8 (and so on ad infinitum)  But I'm also pointing out the obvious problem and an obvious simple fix which doesn't involve inventing a whole new system.  I would have thought that this should at least spark some enthusiasm.

It's unfortunate, maybe, that I only realized so late that the pythread GIL was implemented using a homebrew condition variable mechanism.  I always thougth (being a windows guy) that it were simply using the pthread_mutex() and thus the greedy behaviour of the GIL could be ascribed to that.

Anyway, I´ll continue giving this patch some love.  I wouldn't be surprised if it, and especially the "priority" variant, would be appealing to people doing e.g. webservers with 2.x technology.

Another thing that the "priority" patch has done is convince me that I really need to implement this scheduling mode in stackless, since it does appear to help network latency when using FIFO scheduling of threads / tasklets.

Cheers!