Vladimir Matveev <[email protected]> added the comment:
To bring in analogy: C# has lock statement that allow to run a block of code
holding a mutual-exclusion lock on some object.
```
lock(o)
{
}
```
is compiled as
```
object _lock = o;
bool _lockTaken = false;
try
{
System.Threading.Monitor.Enter(_lock, out _lockTaken);
...
}
finally
{
if (_lockTaken)
{
System.Threading.Monitor.Exit(_lock);
}
}
```
In C# System.ThreadAbortException can be raised in arbitrary point in code and
yet lock statement needs to to enforce the invariant "if lock is taken it will
be released". In order to do so:
- lock acquisition is performed inside the try block, as a side effect it sets
the value of '_lockTaken' passed as out parameter - these two actions are
performed atomically and cannot be interrupted by the asynchronous exception
- lock is released in finally block only if lock was previously taken. Also
finally blocks in .NET has a property that they cannot be interrupted by
asynchronous exceptions so call to Monitor.Exit is guaranteed to be run if
control flow has entered matching try block.
I feel that something similar can be used to solve this issue as well.
Discussions for issue29988 has already mentioned adding special semantic to
__enter__/__exit__ methods or marking bytecode ranges as atomic to make sure
that they are not interrupted. While the former case is specific to with
statements, the latter one can probably be generalized to support finally
blocks as well.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34486>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
