[Python-Dev] Why did Fredrik leave the party?

Brett Cannon bac@OCF.Berkeley.EDU
Wed, 5 Feb 2003 15:09:35 -0800 (PST)


[Barry A. Warsaw]

>
> >>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
>
>     GvR> There's also the tension between making the language simpler
>     GvR> (to learn) and making programs simpler (to read).  For
>     GvR> example, *if* (and that's still a very big if) we were to add
>     GvR> a language feature that would let you write
>
>     |     synchronized(lock):
>     |         BLOCK
>
>     GvR> instead of
>
>     |     lock.aqcuire()
>     |     try:
>     |         BLOCK
>     |     finally:
>     |         lock.release()
>
> The real problem is that the second example isn't even correct, if you
> want to be totally anal about it. ;)  You really need an atomic
> operation to acquire the lock and enter the try block, which the
> second example doesn't give you.  It's a narrow window of failure but
> it exists, and you have to decide whether you care.  So the first
> example doesn't /just/ improve readability, it improves correctness
> too (assuming it is also atomic).
>

What about having keywords that denote that something be executed as
atomic?  I assume the issue is being in the middle of executing bytecode
and then switching threads in the middle of the bytecode for the method
execution.  Would it be reasonable (and feasible) to implement some way to
shut down thread switching in the interpreter and thus guarantee that
something gets fully executed before allowing thread switching (I am
thinking of something along the lines of a lock that keeps track of the
number of thread switching shutdown calls and then turns back on switching
when the counter hits back down to 0).

Or am I missing something critical and thus I should just shut up?  =)

-Brett