Re: dlmopen with RTLD_GLOBAL

[Elliott Slaughter <elliottslaughter at gmail dot com>]

On Fri, Jun 30, 2017 at 2:58 PM, Toebs Douglass <toby@winterflaw.net> wrote:
> What happens while the GIL is held?  *why* is the GIL held?
>
> I heard some talk of replacing the GIL with lock-free data structures.

As a disclaimer: I am not a Python developer nor do I follow Python
development very closely.

My impression is that the reason for the GIL is that the Python
developers (and particularly Guido) value implementation simplicity
over most other things (such as efficiency). Using a single, global
lock is the limit on how simple you can make the Python implementation
without throwing out support for threading altogether. And they're
right to the extent that more fine-grained locking (or lock-free data
structures) would require developers to actually reason about how they
use their data structures.

At this point it's also a backwards-compatibility concern because the
GIL is exposed via the C/C++ API and thus accessible to native
modules.

Granted, I am not really plugged in to this community so maybe the
tides are changing. However, based on my limited knowledge I would
guess that they'd be resistive to "more advanced" approaches to
concurrency, even if those approaches would bring various benefits.
Maybe this would have more luck in the alternative Python interpreter
communities, but native module compatibility will still be a sore
point.

Like I said in my last post, in practice what I see people doing most
often is using multiple processes for parallelism. There have been
fledgling attempts at making multiple distinct Python interpreters in
a single process, and as best I can tell little to no effort on
supporting parallelism within a single interpreter.


-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it." - Alan Kay