[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency, again
From: |
Ken Raeburn |
Subject: |
Re: Concurrency, again |
Date: |
Tue, 18 Oct 2016 06:08:49 -0400 |
> 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.
- Re: Emacs as browser (was Re: Concurrency, again), (continued)
- Re: Emacs as browser (was Re: Concurrency, again), Perry E. Metzger, 2016/10/20
- Re: Concurrency, again, Philipp Stephani, 2016/10/25
- Re: Concurrency, again, joakim, 2016/10/12
- Re: Concurrency, again, John Wiegley, 2016/10/12
- Re: Concurrency, again, SAKURAI Masashi, 2016/10/15
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Tom Tromey, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/18
- Re: Concurrency, again, Ken Raeburn, 2016/10/18
- Re: Concurrency, again, Eli Zaretskii, 2016/10/18
- Re: Concurrency, again,
Ken Raeburn <=
- Re: Concurrency, again, Eli Zaretskii, 2016/10/18
- Re: Concurrency, again, Ken Raeburn, 2016/10/19
- Re: Concurrency, again, Eli Zaretskii, 2016/10/19
- Re: Concurrency, again, Ken Raeburn, 2016/10/20
- Re: Concurrency, again, Eli Zaretskii, 2016/10/20
- RE: Concurrency, again, Herring, Davis, 2016/10/20
- Re: Concurrency, again, Ken Raeburn, 2016/10/20
- Re: Concurrency, again, Paul Eggert, 2016/10/20
- Re: Concurrency, again, Alan Third, 2016/10/18
- Re: Concurrency, again, Ken Raeburn, 2016/10/19