[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
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