A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-list/2005-September/348058.html below:

global interpreter lock

global interpreter lockBryan Olson fakeaddress at nowhere.org
Thu Sep 1 02:15:38 EDT 2005
Mike Meyer wrote:
 > Bryan Olson writes:
 >>System support for threads has advanced far beyond what Mr. Meyer
 >>dealt with in programming the Amiga.
 >
 > I don't think it has - but see below.
 >
 >>In industry, the two major camps are Posix threads, and Microsoft's
 >>Win32 threads (on NT or better).  Some commercial Unix vendors have
 >>mature support for Posix threads; on Linux, the NPTL is young but
 >>clearly the way to move forward.
 >
 > I haven't looked at Win32 threading. Maybe it's better than Posix
 > threads. Sure, Posix threads is better than what I dealt with 10 years
 > ago, but there's no way I'd call it "advanced beyond" that model. They
 > aren't even as good as the Python Threading/Queue model.

Ever looked under the hood to see what happens when you wait
with a timeout on a Python queue/semaphore?

With Python threads/queues how do I wait for two queues (or
locks or semaphores) at one call? (I know some methods to
accomplish the same effect, but they suck.)

 >>Java and Ada will wrap the native thread package, which
 >>C(++) offers it directly.
 >
 > Obviously, any good solution will wrap the native threads [...]

I recommend looking at how software that implements
sophisticated services actually words. Many things one
might think to be obvious turn out not to be true.


-- 
--Bryan

More information about the Python-list mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4