Re: the state of the concurrency branch

[Eli Zaretskii]

> From: Tom Tromey <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, Juanma Barranquero <address@hidden>,
>         address@hidden
> Date: Mon, 26 Aug 2013 20:30:46 -0600
> 
> The basic issue is that only one thread can select on a given fd at a
> time.  This means we have to track which threads are currently selecting
> on which fds; and also it means we must recompute the various select
> masks dynamically.

What about the keyboard fd? is it selected by all threads, or just by
some?  If the latter, by which one(s)?

Also, what about the special inputs, such as file notifications etc.,
which currently just stuff some events into the keyboard queue -- how,
if at all, shall that change when more than one thread could be
running and watching those events?

And a related question: what about triggering redisplay, which is done
as part of waiting for some input -- will it be triggered by more than
one thread now?

> Stefan> --- src/lisp.h        2013-08-25 20:25:59 +0000
> Stefan> +++ src/lisp.h        2013-08-26 21:03:23 +0000
> Stefan> @@ -535,6 +535,7 @@
> Stefan>      ptrdiff_t size;
> Stefan>    };
>  
> Stefan> +/* FIXME: Including thread.h here is odd, we normally don't do that. 
>  */
> Stefan>  #include "thread.h"
>  
> Yeah.  The ordering is funky due to the #define hack.

It was the main reason for breaking the Windows compilation, btw.  We
have now an unfortunate situation whereby lisp.h cannot be included
before some of the other headers, due to this.

> Stefan> +/* FIXME: Why "m_"?  */
> 
> I don't recall why "m" in particular

It probably stands for "member".  This is a widely used coding
convention, except that Emacs never used it -- until now.  We use foo_
in other places for similar reasons, perhaps we should do that here as
well, for consistency, if nothing else.

Here are a few more questions/comments, based on some reading of the
code.  Some of the below is relevant to how the infrastructure in
systhread.c might be ported to Windows.  In no particular order:

 . The compute_*_wait_mask functions in process.c could use some more
   meaningful names, to more clearly indicate their semantics from the
   caller's POV.  Right now, the names simply state which bits are
   tested in the fd's flags (and even that is not 100% accurate, since
   e.g. the FOR_READ flag is not mentioned).  That is hard on mnemonic
   memory, especially since some of the functions define their purpose
   in negative form (compute_NON_keyboard_wait_mask).

 . Why is systhread.c on a separate file?  Wouldn't it be better to
   have this code in thread.c instead?  It's not like thread.c can be
   compiled in without also compiling systhread.c, right?

 . Will the handling of SIGCHLD be thread-specific or global?  IOW, if
   a thread fires up a subprocess, which exits while another thread is
   running, which thread(s) will get the signal?  If the signal
   arrives at some other thread, how will that thread know to handle
   it, if it doesn't watch the corresponding fd's?

 . I'm not sure I understand the rationale for the synchronization
   primitives that were implemented.  AFAIU, we have mutexes, and we
   have condition variables, and their basic functionalities are
   exposed all the way to the Lisp level.  But mutexes are implemented
   as condition variables under the hood.  Why is that? is that only
   to be able to interrupt a wait for mutex without relinquishing the
   mutex?  If the latter, then what is the real difference between
   these two, since both condition variable is also released by
   signaling it?  (Btw, the lispref manual mentions
   'condition-signal', does it mean 'thread-signal' instead? there's
   no mention of 'condition-signal' anywhere else, AFAICS.)

 . The issue with signals to thread is unclear to me.  threads.texi
   says:

     @defun thread-signal thread error-symbol data
     Like @code{signal} (@pxref{Signaling Errors}), but the signal is
     delivered in the thread @var{thread}.  If @var{thread} is the current
     thread, then this just calls @code{signal} immediately.
     @code{thread-signal} will cause a thread to exit a call to
     @code{mutex-lock}, @code{condition-wait}, or @code{thread-join}.
     @end defun

   A call to 'signal' throws to a handler or to top level, but what
   does the latter mean in a thread, where (AFAIU) there's no top
   level? will the thread be forced to exit (there's a hint that "a
   thread cannot be exited, but [...] other threads can be signaled")?
   if not, what will happen to it, after it exits the blocking wait
   calls?  And how is this thread signaling a generalization of the
   current single-threaded 'signal'?

 . threads.texi mentions the "current thread", but never explains what
   that is.  For Lisp code, that's probably the thread which runs the
   code, but what, if anything, does "current thread" mean on the C
   level?  Since several threads could potentially be running at the
   same time, is there any meaning to talk about "current thread"
   except in the context of some Lisp code?

   And what about the main thread, btw, the one created when Emacs
   starts?  Is that thread "more equal than others", or is it just
   like the others?

 . If a thread dies (because the underlying thread implementation hits
   some fatal error) while it holds a mutex, will the mutex be
   released?

 . Finally, if condition variables are unavailable (they are a pain on
   Windows, since only the latest versions support them natively), is
   it still possible to have threads, just without some
   synchronization features?  Or are condition variables currently a
   must for the threading mechanism itself?

Well, that's enough for now.  Thanks in advance for reading and
commenting.