Re: Concurrency, again

[Ken Raeburn]

> On Oct 18, 2016, at 05:22, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Ken Raeburn <address@hidden>
>> Date: Tue, 18 Oct 2016 03:58:04 -0400
>> Cc: address@hidden
>> 
>> I collected some notes from those past discussions, though it was often 
>> unclear whether there was consensus on certain things being needed or 
>> whether they were just ideas being kicked around.  My list, aside from the 
>> note to go back and review the discussions again :-) …
>> 
>> * collapse systhread and thread, adding w32threads.c to emulate the pthread 
>> interface
> 
> This can be done later, it's not a critical issue, IMO.
> 
>> * 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.”

> 
>> * field names and faking globals with macros: maybe change m_ prefix, maybe 
>> add BVAR-like macro
> 
> Again, not critical.


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

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

> 
>> * handle errors in lower-level routines like sys_cond_init
>> * ns_select needs fixing
>> 
>> There are also uses of jmp_buf in places that should be examined carefully, 
>> like stack overflow handling, keyboard.c:getcjmp, and image handling code.
> 
> I'd say, insert appropriate FIXME comments where these issues pop up,
> and leave this for later, unless the solution is already known.

It’s easy enough to disable stack overflow checking when enabling thread 
support.  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.  The keyboard.c one is the only 
one I’m a bit concerned about, in part because I haven’t looked at it.