decorators vs GIL

[Donn Cave]

In article <96c2e938.0408101428.1545fb26 at posting.google.com>,
 sjdevnull at yahoo.com (G. S. Hayes) wrote:
> mudd at vex.net wrote in message 
> news:<mailman.1441.1092142125.5135.python-list at python.org>...
...
>>  I'm really not concerned with how the threads are implemented in the 
>> thread library.  I just don't want a language to prevent me from 
>> accessing the thread library.
> 
> I agree, though I'd much rather use a language like Python that hides
> the thread library than a language like Java that hides the much more
> useful process library.

May have missed some of the context here, I suspect there's
a particular language that's preventing some particular type
of access to the thread library, but the details seem to be
missing.

In more general terms, note that some languages implement
threads on their own, rather than integrating with the OS
thread system.  That doesn't work for me, but for some
applications it's said to be much more efficient and robust.
Erlang is probably a good example, the great "microthreads"
stackless add-on of yore probably a more interesting one.

It would be interesting to get someone to revive microthreads,
and someone else to restore the free threading patches, and
then try both on the same compute intensive pure Python
problem on a 4-way Xeon.  Microthreads would of course be
limited to one processor, but I wouldn't bet a dime on the
outcome.

   Donn Cave, donn at u.washington.edu