On Tue, Sep 25, 2018 at 1:10 AM Erik Bray wrote:
>
> On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote:
> >
> > On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski
> > wrote:
> > > Since the java.lang.Thread.stop() "debacle", it has been obvious that
> > > stopping code to run other code has
On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote:
>
> On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski
> wrote:
> > Since the java.lang.Thread.stop() "debacle", it has been obvious that
> > stopping code to run other code has been dangerous. KeyboardInterrupt
> > (any interrupt really) is
On Thu, Sep 20, 2018, 3:52 PM Kyle Lahnakoski
wrote:
> KeyboardInterrupt (any interrupt really) is dangerous. Now, we can
> probably code a solution, but how about we remove the danger
>
The other day I accidentally fork-bombed myself with Python os.fork in an
infinite loop. Whoops. It seems to
On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski wrote:
> Since the java.lang.Thread.stop() "debacle", it has been obvious that
> stopping code to run other code has been dangerous. KeyboardInterrupt
> (any interrupt really) is dangerous. Now, we can probably code a
> solution, but how about we
On 2017-06-28 07:40, Erik Bray wrote:
> Hi folks,
Since the java.lang.Thread.stop() "debacle", it has been obvious that
stopping code to run other code has been dangerous. KeyboardInterrupt
(any interrupt really) is dangerous. Now, we can probably code a
solution, but how about we remove the
Nathaniel Smith wrote:
A magic (implemented in C) decorator like @async_signals_masked I
think would be the simplest way to do this extension.
I don't have a good feeling about that approach. While implementing
the decorator in C might be good enough in CPython to ensure no
window of
Nathaniel Smith wrote:
So what should this async_signals_masked state do when we yield out
from under it? If it's a thread-local, then the masking state will
"leak" into other async function callstacks (or similar for regular
generators), which is pretty bad. But it can't be just frame-local
On Wed, Jun 28, 2017 at 6:19 AM, Greg Ewing wrote:
> Erik Bray wrote:
>>
>> At this point a potentially
>> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised
>> while inside the with statement's suite, and finally block, and hence
>> Lock.__exit__
Erik Bray wrote:
My question would be to
make that a language-level requirement of the context manager
protocol, or just something CPython does...
I think it should be a language-level requirement, otherwise
it's not much use.
Note that it's different from some existing CPython-only
behaviour
On Wed, Jun 28, 2017 at 3:19 PM, Greg Ewing wrote:
> Erik Bray wrote:
>>
>> At this point a potentially
>> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised
>> while inside the with statement's suite, and finally block, and hence
>> Lock.__exit__
On Wed, Jun 28, 2017 at 3:09 PM, Erik Bray wrote:
> On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote:
>> On 28 June 2017 at 21:40, Erik Bray wrote:
>>> My colleague's contention is that given
>>>
>>> lock = threading.Lock()
Erik Bray wrote:
At this point a potentially
waiting SIGINT is handled, resulting in KeyboardInterrupt being raised
while inside the with statement's suite, and finally block, and hence
Lock.__exit__ are entered.
Seems to me this is the behaviour you *want* in this case,
otherwise the lock can
On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote:
> On 28 June 2017 at 21:40, Erik Bray wrote:
>> My colleague's contention is that given
>>
>> lock = threading.Lock()
>>
>> this is simply *wrong*:
>>
>> lock.acquire()
>> try:
>> do_something()
On 28 June 2017 at 21:40, Erik Bray wrote:
> My colleague's contention is that given
>
> lock = threading.Lock()
>
> this is simply *wrong*:
>
> lock.acquire()
> try:
> do_something()
> finally:
> lock.release()
>
> whereas this is okay:
>
> with lock:
>
14 matches
Mail list logo