GNU bug report logs - #25214
26.0.50; Interacting with user from threads other than the primary

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25214 <at> debbugs.gnu.org, tom <at> tromey.com
Subject: bug#25214: 26.0.50; Interacting with user from threads other than the primary
Date: Tue, 18 Sep 2018 10:21:35 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> In order to fix the problem of reading input in a non-primary thread, we
>> need a new function which request I/O control to the current thread. It
>> needs
>>
>> * to request control for the keyboard. This could be indicated by a
>>   signal to the main thread, which is *not* an error signal but a
>>   special one, let's call it `thread-set-keyboard'.
>>
>> * to handle this signal in `thread-handle-event', by calling a
>>   respective function (let's call it `thread--set-keyboard'). This
>>   function sets the struct event thread to the thread which has
>>   delivered by the `thread-set-keyboard' signal. Next time fd_mask is
>>   prepared, the keyboard fd would be taken into account for the
>>   requesting thread.
>>
>> * to stop/recall the recent pselect for the main thread in order to free
>>   the keyboard fd. Don't know how to do this.
>>
>> * to provide a mechanism which resets the thread struct field of the
>>   keyboard fd to NULL, in order to let the main thread use the
>>   keyboard. Here I have also no idea how to do this.
>
> It's not all we need (remember all that talk about serializing access
> to the echo area?), but it's a beginning.

Exactly.

> And the crucial piece is bullet #3, because thread-signal will not
> interrupt the pselect call.  And if we are not too lucky, the pselect
> call could have been made with a long timeout.  So this is the first
> obstacle to negotiate.

Yes. There is quit_throw_to_read_char, but this would quit the (main)
thread, which is not what we want.

> So what means do we have to interrupt a pselect call from another
> thread?
>
> (I'm not sure I understand why you thought we'd need bullet #2, btw.
> Once we interrupt the pselect call, the main thread should become
> stuck trying to take the global lock, so I don't think we need any
> trickery here, because the other thread, which is running, will have
> arranged for it to be the current thread.)

Shouldn't there be several read_char calls in parallel? Bullet #2 is
just a machinery to switch to the main thread, that's all. If we could
manipulate the main thread from inside current thread, we wouldn't need this.

> Thanks.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.