Re: The event handling thread

[Eli Zaretskii]

> From: Elias Mårtenson <address@hidden>
> Date: Thu, 22 Dec 2016 11:12:08 +0800
> Cc: emacs-devel <address@hidden>
> 
>  > But that doesn't change the fact that it makes more sense to never allow 
> keyboard input to be
>  processed by
>  > anything other than the main thread?
> 
>  Why does it make more sense than, say, serialize access to the
>  minibuffer such that only one thread can access it at a time?
> 
> It would, if the minibuffer was the only place where the keyboard was read. 
> However, isn't this problem wider
> than just the minibuffer?

It is.  But minibuffer input is IMO the most urgent issue to solve,
because Emacs interacts with the user like that quite a lot.

> In my tests with ‘sit-for’ and threads, I noticed that if multiple threads do 
> ‘sit-for’ at the same time, and a press
> a key, then only one of the threads gets released. As you keep generating 
> input, more and more of the threads
> exit the call to ‘sit-for’. A central input processing thread would fix this 
> issue too, right?

Could you show some code where this can be seen?  I'm not sure I
understand how exactly this happens.  What I saw in my testing is that
only the primary thread waits on the keyboard descriptor, but maybe
I'm missing something.  Perhaps your tests made the primary thread
yield, or wait on some synchronization object?

>  > C-g isn't "normal" keyboard input, is it?
> 
>  It depends. It's a bit of both, at least on GUI frames.
> 
> Is this related to the messy event loop in GTK Emacs that people were 
> commenting on in some other thread
> recently?

It is related to that, and also to how C-g and keyboard input are
treated in other configurations we support.  AFAIR, TTY, X11, GTK, and
w32 -- each one of these has its own slightly different model of
handling keyboard input and C-g.  Probably NS has yet another one.