[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency
From: |
Stefan Monnier |
Subject: |
Re: Concurrency |
Date: |
Mon, 29 Mar 2010 13:39:36 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Tom> * Suppose you have existing elisp that creates a process with a filter,
Tom> and the filter changes a let-bound variable, and the "outer" elisp
Tom> blocks in sit-for waiting for the filter to do its thing. Nothing in
Tom> the current code guarantees that the process filter will be run in the
Tom> "correct" thread.
Ken> That may be a reason to force the filter to run in the same thread
Ken> that created it.
> Yeah. I was thinking perhaps process filters could have a thread
> attribute, which would default to their creating thread. Setting this
> to nil could mean that the process filter could run in any thread.
Or maybe accept-process-output should cause the filters to be run in the
waiting thread (especially when the `proc' argument is provided).
Stefan
- Re: Concurrency, (continued)
- Re: Concurrency, Tom Tromey, 2010/03/28
- Re: Concurrency, Daniel Colascione, 2010/03/28
- Re: Concurrency, Stefan Monnier, 2010/03/28
- Re: Concurrency, Tom Tromey, 2010/03/28
- Re: Concurrency, Tom Tromey, 2010/03/28
- Re: Concurrency, Ken Raeburn, 2010/03/29
- Re: Concurrency, Tom Tromey, 2010/03/29
- Re: Concurrency,
Stefan Monnier <=
- gsoc for concurrent Emacs? (was: Concurrency), Ted Zlatanov, 2010/03/31
- Re: Concurrency, Giuseppe Scrivano, 2010/03/28
- Re: Concurrency, Daniel Colascione, 2010/03/28
- Re: Concurrency, Tom Tromey, 2010/03/28