Re: Blocking calls and threads

[Lynn Winebarger <owinebar@gmail.com>]

On Thu, Apr 20, 2023 at 9:28 AM Po Lu <luangruo@yahoo.com> wrote:
> Lynn Winebarger <owinebar@gmail.com> writes:
> > Presumably whatever mechanism is used for the calls you identified
> > below could be generalized.  In practical terms, it would mean
> > assigning locks to every system resource that isn't inherently part of
> > the lisp machine, in this case at least file descriptors.  Then, for
> > example, the read call in emacs_intr_read (in sysdep.c) could be
> > surrounded by a release of the global lock (which yields the thread of
> > the lisp machine) and the re-acquisition of the global lock.  The file
> > descriptor lock might be acquired after yielding the lisp thread, or
> > it might be owned exclusively by the thread that opened it.
>
> I'm afraid that's not so easy.  Parts of Emacs have certainly been
> designed with the assumption that context switching cannot happen inside
> read and friends; at least the Android and NS ports have this problem.

I didn't mean to imply that was *all* that was required - although I
would distinguish concerns around maintaining consistency of the Lisp
machine state (heap/globals) from the correctness of Lisp code that
has race conditions on buffer objects, etc.  I'm not saying the latter
don't have to be addressed, just that they pose distinct engineering
problems from the former.  It's not unlike the move from dynamic to
lexical scope.  Perhaps some day there will be a `thread-safe' local
variable.

> > Are these identified as a group anywhere for reference?  Otherwise, I
> > don't know what is included in the "etc".
>
> Basically anything that calls `thread_select'.  This includes almost
> everything that waits for input.  Please grep around in the C sources.

Thanks,
Lynn