Parallelization on muli-CPU hardware?
daniel.dittmar at sap.corp
Thu Oct 7 17:30:59 CEST 2004
> 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.
More information about the Python-list