Embedding Python, threading and scalability

[Aahz]

In article <mailman.1057941919.10103.python-list at python.org>,
Jeff Epler  <jepler at unpythonic.net> wrote:
>On Thu, Jul 10, 2003 at 07:48:57PM -0400, Aahz wrote:
>> In article <mailman.1057877718.17081.python-list at python.org>,
>> Jeff Epler  <jepler at unpythonic.net> wrote:
>>>On Thu, Jul 10, 2003 at 03:54:14PM -0400, Aahz wrote:
>>>>
>>>> Other people have mentioned Perl and Tcl in this thread.  I wonder how
>>>> they deal with the problem of loading DLLs with static data.
>>>
>>>As far as I know, tcl enforces a one interpreter to one thread
>>>requirement.  An extension should have only thread-local data, using a
>>>Tcl-supplied API.
>> 
>> What happens when Tcl wants to interact with some 3rd-party DLL that is
>> *not* thread-safe?
>
>I guess you'd have to do your own locking.  Tcl has standard C APIs for
>Conditions, Mutexes, and thread-specific data, see the Thread(3) manpage.
>You'd have to surround all non-reentrant calls with Tcl_MutexLock(m)
>... Tcl_MutexUnlock(m).  If two extensions wanted to use the same
>non-thread-safe library, they'd have to cooperate in some way to use
>the same 'm' to Tcl_Mutex*().  I don't know if there's a standard way to
>do this, but I think that having the mutex defined in a shared lib they
>both link might work.

Yup.  And that's exactly why there has been little movement to remove
the GIL from Python.  One of Python's core strengths is the ease with
which random DLLs can be used from Python.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Not everything in life has a clue in front of it...."  --JMS