Re: Concurrency, again

[Ken Raeburn <raeburn@raeburn.org>]

> On Oct 17, 2016, at 23:14, Tom Tromey <tom@tromey.com> wrote:
> 
>>>>>> "John" == John Wiegley <jwiegley@gmail.com> 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