[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the state of the concurrency branch
From: |
Tom Tromey |
Subject: |
Re: the state of the concurrency branch |
Date: |
Fri, 18 Oct 2013 12:16:59 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:
>> It seems reasonable to me. However I wonder whether timers ought to be
>> thread-locked the way that processes are.
Stefan> Ideally, neither should be thread-locked. So I'd rather not lock
Stefan> it/them unless it's needed for backward compatibility.
I think the bad case is a situation where some code dynamically binds
some variable and then sleeps, knowing that the timer will fire and see
the binding.
If there are multiple threads, the sleep may switch threads and cause
the timer to run in a different dynamic environment.
Whether this warrants thread-locking, I couldn't say.
I don't know whether this sort of thing is common for timers.
Tom
- Re: the state of the concurrency branch, Barry OReilly, 2013/10/16
- Re: the state of the concurrency branch, Barry OReilly, 2013/10/16
- Re: the state of the concurrency branch, Tom Tromey, 2013/10/17
- Re: the state of the concurrency branch, Tom Tromey, 2013/10/17
- Re: the state of the concurrency branch, Stefan Monnier, 2013/10/18
- Re: the state of the concurrency branch,
Tom Tromey <=
- Re: the state of the concurrency branch, Richard Stallman, 2013/10/19
- Re: the state of the concurrency branch, Barry OReilly, 2013/10/19
- Re: the state of the concurrency branch, Stefan Monnier, 2013/10/19
- Re: the state of the concurrency branch, Barry OReilly, 2013/10/19
- Re: the state of the concurrency branch, Tom Tromey, 2013/10/21
- Re: the state of the concurrency branch, Barry OReilly, 2013/10/21
- Re: the state of the concurrency branch, Stefan Monnier, 2013/10/21
- Re: the state of the concurrency branch, Stefan Monnier, 2013/10/21
- Re: the state of the concurrency branch, Barry OReilly, 2013/10/19