[Python-Dev] Making python C-API thread safe (try 2)

Pettersen, Bjorn S BjornPettersen at fairisaac.com
Wed Sep 17 21:32:13 CEST 2003

> From: Harri Pesonen [mailto:fuerte at sci.fi]
> Jeff Epler wrote:
> > On Tue, Sep 16, 2003 at 08:22:41PM +0300, Harri Pesonen wrote:
> > >
> > > It is more efficient to have one process and several threads, than
> > > several processes each having one thread.
> >   
> >
> > If it's easier to code "several processes each having one thread",
> > I'll sure do it.  I've accepted a 2x-100x speed hit by using Python,
> > if it's a 25% difference in efficiency, I won't sign up to wait for
> > that doesn't exist yet.
> But wouldn't it be better if Python had real multitasking? Comments
like the
> above mean that you accept Python as it is, fine. But usually people
want to
> make things better when they see that something can be improved. If my
roof is
> leaking, I have two choices: fix it or accept it. If I am able to fix
it, then
> I'll probably do it.

No, comments like the above realizes that there are certain tradeoffs.
counting as a primary garbage collection mechanism is fundamentally
with multithreading in an object oriented language -- unless you have
factors like the GIL. The number of locking operations quickly overwhelm
computation. (I'm aware that you don't want shared data, however I
fail to see the utility..)

There is some research indicating that generational gc is more efficient
regards to total program run time in heavily mt oo applications, so
certainly an interesting area to look into -- it would, however, require
fundamentally different language implmentation (one which didn't have
the nice 
finalization guarantees CPython currently has).

When it comes to applicability, I'm assuming you're not heading in this 
direction to do heavy computational work in pure Python(?) If all you
want to do 
is watch your Python programs run maximally paralell, I would suggest
Jython as 
an alternative without a GIL...

-- bjorn

More information about the Python-list mailing list