Re: Concurrency, again

[Eli Zaretskii]

> From: Ken Raeburn <address@hidden>
> Date: Tue, 18 Oct 2016 06:08:49 -0400
> Cc: address@hidden,
>  address@hidden
> 
> >> * header inclusion order requirement is weird; can generating one big 
> >> header help?
> > 
> > I'm not sure I understand what inclusion order is being alluded to
> > here.  Can you elaborate?
> 
> I think it’s the ordering and recursive inclusion involving thread.h relative 
> to the other headers.  For example lisp.h includes thread.h which includes 
> sysselect.h which includes lisp.h; thread.h uses struct vectorlike_header, so 
> it has to be included in lisp.h after that structure is defined but before 
> struct thread_state gets used; thread.h also includes regex.h which includes 
> lisp.h.  You commented at one point, “We now have an unfortunate situation 
> whereby lisp.h cannot be included before some of the other headers, due to 
> this.”

This could be solved by moving parts of thread.h into lisp.h, with the
appropriate #ifdef guards.  I think Lisp objects should be in lisp.h
anyway, even if they are optional; anything else is confusing.

> >> * one thread per terminal?
> > 
> > Why?
> > 
> >> * file notifications and such shouldn’t go through same queue as keyboard 
> >> events
> > 
> > Why?
> 
> Stefan’s message: 
> http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00755.html

I don't see that as a critical problem, perhaps because we don't yet
realize how serious it can be.  The whole purpose of trying to merge
the concurrency branch is to collect practical experience as to what
should and shouldn't be in this kind of Emacs feature.  So I'd tend to
let this be, until we find out we can't, and why.

> >> * interaction of SIGCHLD handling and threads?
> > 
> > Details?
> 
> Your message 
> http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00738.html raised 
> questions.  If they were ever satisfactorily answered, I overlooked it when 
> putting together my notes….

That should be easy: since a subprocess is locked to a single thread,
SIGCHLD should be delivered to that thread.  If we don't have that
already, we should add that, it doesn't sound hard, given the
infrastructure we already have (deliver_thread_signal etc.).

> It’s easy enough to disable stack overflow checking when enabling thread 
> support.

Or add some simple code in the stack overflow handler to check if we
are in the main thread, and if not, punt (i.e. crash).

> If only one thread is allowed into the image processing code at a time (i.e., 
> don’t release the global lock for that code) then that’s probably fine for 
> now, and there’s probably other state there that different threads shouldn’t 
> be mucking around with in parallel.

Redisplay runs in the main thread anyway, right?  If so, there's no
problem.

> The keyboard.c one is the only one I’m a bit concerned about, in part because 
> I haven’t looked at it.

What part(s) of keyboard.c, exactly?

Thanks.