Re: Blocking calls and threads

[Lynn Winebarger <owinebar@gmail.com>]

On Thu, Apr 20, 2023 at 3:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Thu, 20 Apr 2023 01:31:14 -0400
> >
> > The thread on how to make asynchronous behavior explicit made me
> > curious whether making a blocking system call would cause the lisp
> > thread to yield to other lisp threads (release the global lock).  Do
> > blocking system calls yield the lisp thread, or is there any way in
> > lisp code to call blocking functions so that the lisp thread will
> > yield while the system thread blocks?
>
> What do you mean by "blocking system calls", exactly?
>
> If you mean the likes of 'read' and 'write' (i.e. "blocking system
> calls" on the OS level),

Almost - I mean the subrs that make those operations available to the
lisp machine, e.g. insert-file-contents.

> then no, a thread which makes these calls
> will not yield.  How can it? the implementation of those calls is not
> in Emacs, so how can Emacs change the way these syscalls work?

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.

>
> The "blocking system calls" which do yield are calls emitted from
> Lisp: accept-process-output, sit-for, read-key-sequence, etc.

Are these identified as a group anywhere for reference?  Otherwise, I
don't know what is included in the "etc".

Thanks,
Lynn