Re: Concurrency

[Tom Tromey <tromey@redhat.com>]

>>>>> "Ken" == Ken Raeburn <raeburn@raeburn.org> writes:

Tom> * The current code makes no attempt to portable, it relies on POSIX
Tom> threads and the GNU __thread extension.  This is not too hard to
Tom> fix.  I think it is reasonably important to keep __thread on
Tom> systems that support it, for performance.

Ken> Dealing with __thread shouldn't be hard if it's not used
Ken> pervasively, so pthread_{get,set}specific calls can be used in its
Ken> place.

There is exactly one __thread variable.

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.

Ken> Perhaps process filters could be run at thread-switch opportunities
Ken> like 'yield', too?  (And vice versa -- perhaps calls that permit
Ken> the running of process filters should also permit thread
Ken> switching?)

I think (but am not 100% sure) that this already happens -- IIUC, things
like sleep-for and sit-for end up in wait_reading_process_output, which
has a possible yield in it.

Tom