python threads and the linuxthread pthread library

[holger krekel]

- c o v e n t r y - wrote:
> 
> > 
> > Does Jython lift this limitation, by any chance? Or is
> > the GIL a universal and unchangable Python artifact?
> 
> I don't know about jython, but _nothing_ is unchangeable (well, almost 
> nothing) - the GIL is whats used right now... Theres no reason to 
> believe that a non-GIL solution couldn't be found if people put thier 
> minds to it - it would be *hard*, and might break compatability (ACK!), 
> but it is possible.

I have been told (at EuroPython and anywhere else) that removing the GIL 
is just too hard.  I'd still like to agree with you :-)

> How about a read-lock on global data? - all threads could maintain thier 
> own locals-state, and just lock on trying to read/write a global...
> of course, first, all code in the current implementation would need to 
> be rentrant for true (OS) threads...

I think its not that much about global data.  Any object can be accessed from 
threads.  Refcounting is the first problem.  Modifying dictionaries 
and lists is the second.  Coming to think of it, these two types are really 
the two types that underly *any* modification!?!  Except maybe for the
global and local namespaces which are highly optimized because of their 
importance.  Other than dicts, lists, namespaces and refcounts what
objects does python actually modify? (ints,strings,tuples,floats etc. are immutable).

Based on these observations i'd guess that interesting stuff could be done.  
I'd like to check out if it is possible to make an object and everything 
it recursively references 'read-only'.  This requires hacking dict-proxy 
objects at the C-level.  They'd have to prevent write-access to themselves 
and everything they pass out (e.g. the value of an attribute lookup).  

Note that there have been discussions on python-dev about adding an
observer-pattern to python objects (get notifications on object
changes).  I think this is much too heavy-weight and a simple read-only
property would be enough for many use-cases.  Most important it would
support Copy-On-Write (COW) - semantics.  Very important for transactional 
systems which have a lot more reads than writes (like e.g. Zope).
Ultimately i'd really like to have extremly lightweight transactional 
behaviour at the language level. 

Of course this doesn't really answer any of your questions about the GIL but
i have the gut feeling that having read-only mechanisms at the type 
level would be a step towards a relaxed GIL handling ...

really just my 2c,

    holger