From: Michael Albinus <michael.albinus@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 25214@debbugs.gnu.org, tom@tromey.com
Subject: bug#25214: 26.0.50; Interacting with user from threads other than the primary
Date: Thu, 27 Sep 2018 18:15:08 +0200 [thread overview]
Message-ID: <87o9ciapdf.fsf@gmx.de> (raw)
In-Reply-To: <834lengq5f.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Sep 2018 11:34:36 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
>> > One simple idea is not to interrupt a pselect call, but instead to
>> > make sure the main thread never waits for too long for pselect to
>> > return. We could arrange for acquire_global_lock to maintain a count
>> > of the number of threads that are waiting to take the lock, and if
>> > that number is positive, reduce the timeout we pass to pselect such
>> > that it never waits for more than, say, 1 sec. Then we need a way for
>> > a non-main thread to wait until the main thread returns from pselect,
>> > at which time the non-main thread could proceed with its own attempt
>> > to read input, while the main thread is stuck waiting for the global
>> > lock.
>>
>> I'll see whether I could implement something along this idea. But I'm
>> still learning Emacs' keyboard (more general: FD) handling, so it will
>> take time.
>
> It might help to search for timeout_reduced_for_timers in process.c:
> that's how we implement a similar logic when timers are waiting to
> run.
I've played for a while with the keyboard related code, and I must
confess I'm too dumb for this. Sorry, but it is too much, and I have the
feeling I cannot contribute something useful in this area. So I let this
to be fixed by somebody else. This is a pity, because it blocks further
progress in merging the branch feature/tramp-thread-safe into master.
For the time being I concentrate on tasks I feel better suited, like
adding thread support for further file operations.
Best regards, Michael.
next prev parent reply other threads:[~2018-09-27 16:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-16 15:17 bug#25214: 26.0.50; Interacting with user from threads other than the primary Eli Zaretskii
2016-12-19 4:31 ` Clément Pit--Claudel
2018-09-17 14:06 ` Michael Albinus
2018-09-17 18:41 ` Eli Zaretskii
2018-09-17 19:11 ` Eli Zaretskii
2018-09-18 8:29 ` Michael Albinus
2018-09-18 8:34 ` Eli Zaretskii
2018-09-27 16:15 ` Michael Albinus [this message]
2018-09-27 16:20 ` Eli Zaretskii
2018-09-28 11:09 ` Michael Albinus
2018-09-18 8:21 ` Michael Albinus
2018-09-18 12:33 ` Eli Zaretskii
2019-02-06 6:58 ` bug#25214: #25214 " Zhang Haijun
2019-02-06 15:41 ` Eli Zaretskii
2019-02-07 1:39 ` Zhang Haijun
2019-02-07 14:29 ` Eli Zaretskii
2019-02-07 14:56 ` Zhang Haijun
2019-02-07 17:25 ` Eli Zaretskii
2019-02-08 2:42 ` Zhang Haijun
[not found] ` <D55AF9DD-D8D2-4A59-AE6D-24B597A164C1@outlook.com>
2019-02-07 13:49 ` Zhang Haijun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o9ciapdf.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=25214@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).