Re: Concurrency, again

[Ken Raeburn]

> On Oct 17, 2016, at 23:14, Tom Tromey <address@hidden> wrote:
> 
>>>>>> "John" == John Wiegley <address@hidden> writes:
> 
> John> Tom, if I can find some volunteers to help, would you be willing
> John> to see the work of merging this into master through to completion?
> 
> I can help to some degree, but I definitely can't do it all myself.
> 
> There are two main issues.
> 
> First, it has to be rebased.  There have been a lot of changes since it
> was written -- I tried a rebase last year but it was pretty painful, I
> think I stopped while fixing up the process changes.

I’ve recently been looking at doing another merge, actually.  And yeah, 
process.c is the piece I haven’t finished.

>  The branch is also
> kind of messy, since I think I mostly didn't write ChangeLogs and there
> have been several merges from master.  So I suppose it would need some
> cleanups as well.

Yeah, the lack of documentation on specifics made my last merge (about a year 
ago) challenging.  In fact, in order to get a better understanding of it, I set 
up a private repository where I broke up the concurrency branch changes — not 
each commit, but the overall diff from the branch point — into little pieces, 
separating straightforward but pervasive changes from more subtle changes so I 
could figure out what the latter were doing.  The result of my merge that I 
checked in was in fact the result of rebasing those little changes onto the 
latest master branch, fixing them up as necessary as I went along.  (But the 
resulting body of code was checked in as a merge commit so as to preserve 
history of the work on the branch — what change was put in, who fixed what 
bugs, etc; I wasn’t about to unilaterally throw that away.  It was just a slow, 
tedious, manual merge process instead of an automated one.)

> Second, last time this was discussed there were a reasonably large
> number of comments on features that had to be done in order to merge.  I
> haven't worked on any of those.

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
 * header inclusion order requirement is weird; can generating one big header 
help?
 * field names and faking globals with macros: maybe change m_ prefix, maybe 
add BVAR-like macro
 * one thread per terminal?
 * file notifications and such shouldn’t go through same queue as keyboard 
events
 * interaction of SIGCHLD handling and threads?
 * 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.

Ken