imports and python locking

[Martin Pool]

On Fri, 2005-07-22 at 10:30 -0400, Aaron Bentley wrote:

> Hmm.  We were assuming that it was cheap to import something that was
> already imported, because it's a no-op.  I don't properly understand why
> that's not cheap.  Does even testing whether a module is loaded invoke
> the futex?

The import statement is fairly cheap, because it just does a lookup into
the table of existing imports, and then if it's there inserts into the
caller's namespace.   Nevertheless there is some cost, and it's probably
better not to do it from very hot functions.

The builtin_import needs to take a lock on a module table, to guard
against imports from concurrent threads.  That lock, in turn, suffers
from sem_post always doing a futex wakeup.  I don't understand why they
do that; it seems like it should not be necessary but maybe there is
some subtlety of the posix specification that requires it.

The Python thread locking seems like a bit of an abstraction inversion,
being a very simple mutex built on rather complex libpthread stuff.  It
might be cleaner to just use futexes, which in a brief look seem to
match nicely.  But I'm going to try not to get distracted by that any
more.

-- 
Martin