Home Original page

I just killed GIL!!!

Rhamphoryncus rhamph at gmail.com
Thu Apr 17 13:24:55 EDT 2008 
On Apr 17, 11:05 am, sturlamolden <sturlamol... at yahoo.no> wrote:
> On Apr 17, 6:03 pm, Rhamphoryncus <rha... at gmail.com> wrote:
>
> > Interesting.  Windows specific, but there's other ways to do the same
> > thing more portably.
>
> I believe you can compile Python as a shared object (.so) on Linux as
> well, and thus loadable by ctypes.

Python is compiled as a .so, but I don't believe that makes everything
private to that .so.  Other means may be necessary.

Not that important though.


> > This
> > effectively gives you a multiprocess model - a bit cheaper than that,
> > but not enough to really supply GIL-free threading.
>
> That solution is safe. But I am looking into sharing objects. I don't
> think its impossible.
>
> PyObject* pointers can be passed around. GILs can be acquired and
> released, refcounts increased and decreased, etc. but we have to sort
> out some synchronization details for the shared objects. For one
> thing, we have to make sure that a garbage collector does not try to
> reclaim a PyObject* belonging to another interpreter. But here we are
> talking about minor changes to CPython's source, or perhaps none at
> all.

But can you automatically manage the reference count?  ie, does your
interpreter have a proxy to the other interpreter's object, or does
the object itself gain a field indicating who owns it?

Either way you'll need to keep the number of shared objects to a
minimum, as the use of locking creates a bottleneck - only one thread
can run at a time for a given object.
More information about the Python-list mailing list