Parallelization on muli-CPU hardware?

[Daniel Dittmar]

Aahz wrote:
> One critical reason for the GIL is to support CPython's ability to call
> random C libraries with little effort.  Too many C libraries are not
> thread-safe, let alone thread-hot.  Forcing libraries that wish to
> participate in threading to use Python's GIL-release mechanism is the
> only safe approach.

Most (or many) wrappers around C libs are generated by SWIG, boost, SIP 
and what not. It can't be that difficult to generate code instead so 
that entering extension code acquires a lock end leaving the code 
releases it. And writing an extension by hand is verbose enough, having 
to add the locking code wouldn't really multiply the effort.

One could even add a flag to definitions of native methods that this 
method is reentrant. If this flag isn't set, then the interpreter would 
acquire and release the lock.

Daniel