Re: Blocking calls and threads

[Po Lu <luangruo@yahoo.com>]

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.

> 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.