On Apr 17, 11:05 am, sturlamolden <[EMAIL PROTECTED]> wrote: > On Apr 17, 6:03 pm, Rhamphoryncus <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
