RetroSearch Browse

Tue Mar 14 22:42:15 CET 2006 · http://mail.python.org/pipermail/python-dev/2006-March/062384.html

On Mon, 13 Mar 2006 21:57:59 -0500, Raymond Hettinger wrote:

> Think of it as "non-cooperative" 
> multi-threading. While this is a somewhat rough approach, it is dramatically 
> simpler than the alternatives (i.e. wrapping locks around every access to a 
> resource or feeding all resource requests to a separate thread via a Queue).

Why is that actually more difficult to write? Consider

res_lock = Lock()
res = ...
with locked(res_lock):
    do_something(res)

It is only about supplying the correct lock at the right time. Or even this
could work:

res = ... # implements lock()/unlock()
with locked(res):
    do_something(res)

Directly exposing the GIL (or some related system) for such matters does
not seem to be a good reason for a novice to let him stop all threads.

Kind regards,
Alexander

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

Showing content from http://mail.python.org/pipermail/python-dev/2006-March/062384.html below:

[Python-Dev] Threading idea -- exposing a global thread lock