Re: User interaction from multiple threads

[Michael Welsh Duggan]

Eli Zaretskii <address@hidden> writes:

>> From: Michael Welsh Duggan <address@hidden>
>> Date: Tue, 14 Aug 2018 12:42:04 -0400
>> 
>> #1 If "waiting for input" means in read-from-minibuffer or something
>>    similar, I believe that input should go to the the thread.  The other
>>    thread will have to wait.  If "waiting for input" means idle, it
>>    should go the the other thread.
>
> "Waiting for input" means waiting for user to type something.  That is
> normal Emacs situation when the user does nothing, so unconditionally
> sending input to the main thread and letting the other thread wait
> would mean that other thread might wait indefinitely.

To clarify, I believe the command-loop (main-thread), aside from a large
amount of maintainance, is fundamentally a loop around
read-key-sequence, lookup-key, and command-execute.  *This*
read-key-sequence needs to be interruptable by other threads as long as
no keys have yet been entered into the sequence.  This is the point I
considered to be "idling."  If any other thread, or even the main
thread, calls read-key-sequence outside of the main command-loop, that
one should get the input mutex immediately.

You probably understand what I mean at this point, but to clarify, in
case: Another thread should not be blocked for input because the main
thread is waiting for an event, unless the main thread is waiting for
that event because it explicitly called read-key-sequence or some other
higher-level input function (such as read-from-minibuffer) from anything
other than the command loop.  But the instant the command loop's
read-key-sequence reads a single key, it must have the input mutex until
it has finished reading a key sequence (or is quit).

Now, another command -- say, read-from-minibuffer -- could end up
calling the command loop, which will look for events.  That command
should have set the input mutex beforehand, and, to be clear, this
should be a recursive mutex, so it won't be interrupted in this context.
A call to recursive-edit, however, would not (I think) grab the input
mutex, and as such would still yield to an input request from another
thread.

I have no idea what would be caused by a non-main thread calling
recursive-edit.  That way lies madness.  But someone should consider
what it might mean.


>> #2 You should neveer break a key sequence.  We do not preempt the main
>>    thread.  The other thread will have to wait.
>
> Do we need to tell the user the other thread wants to prompt?

No.  Just wait for the current input sequence to finish, then allow the
prompt.  I suppose there could be indicators in the mode line, or
something like that, but I don't think we need that initialy, and I have
no idea whether that would actually be desirable anyway.

>> User input has to have a beginning and an end.  The simple cases are
>> easy: a single full key sequence or a read-from-minibuffer call.  But in
>> many cases an application has a series of prompts to be asked and
>> answered in succession.  So these inputs need to be able to be grouped
>> somehow along with their prompts.  Then, once a group is executing, any
>> other input-related groups raised by other threads have to wait for the
>> current input group to finish.  Then they cay be served in FIFO or
>> random order.
>> 
>> The easiest was I can think of grouping sets of inputs is as some form
>> of critical section, maybe implemented by mutexes.  This would be
>> simplified for the programmer with a convenience wrapper, something like
>> (with-input-group BODY) or some such.
>> 
>> Unfortunately, this proposal suffers in that it would have to be
>> retroactively added to existing code.
>
> Not necessarily, it could be added to the corresponding primitives.
>
> Thanks.

No problem.  As my employer makes it unfeasibly difficult to contribute
code to the FSF (would have to have a separate disclaimer for every
feature), participating in discussions like this is the least I can do.

-- 
Michael Welsh Duggan
(address@hidden)