emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User interaction from multiple threads


From: martin rudalics
Subject: Re: User interaction from multiple threads
Date: Sun, 19 Aug 2018 11:17:09 +0200

> Unless I'm misunderstanding you, this has everything to do with
> threads, because the input from the newly-selected frame should be
> processed by a different thread than the one which was "current"
> before the switch.

By design, reading input separately for a specific frame would not be
necessarily tied to a thread.  Once complete, the input could be
stored somwhere and later be processed by the main thread.  Only if a
frame is actually owned by a thread, its input would eventually be
passed to that thread.

> thread-signal signals an error (like 'signal' does), so the signaled
> thread will exit as soon as it resumes running, which is not what you
> want.  That's why I mentioned thread-yield.

Then it's probably 'thread-yield' as you mentioned.  I thought
'thread-signal' would allow to resume a specific blocked thread.
I see now that I was wrong.

> What does "left to the thread's writer" mean in this context?  Given
> the low-level details involved, which cannot be done from Lisp, how
> can we leave this to the application?  I'm probably missing something.

When someone like Michael fires off 250 threads at the same time, we
probably need some way to turn off eager frame creation or turn off
frame creation at all by setting some buffer display option.  By
default I would create frames lazily, with frame creation turned off
and eager frame creation as thread specific options.  Once a setting
has been made for a specific thread, the low-level routines have to
act as prescribed by that setting.

>>   > What will appear in the minibuffer window of the previously-selected
>>   > frame while we interact with another thread's frame?
>>
>> If the previously-selected frame was that of the main thread, whatever
>> the main thread currently does.
>
> I don't think this can fly with how redisplay works, can it?

If the main thread's frame is not selected, we do not care much, do
we?  If it's selected, we do whatever we already do now.  Why do you
think redisplay enters here?  What am I missing?

martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]