From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#25214: 26.0.50; Interacting with user from threads other than the primary Date: Thu, 27 Sep 2018 18:15:08 +0200 Message-ID: <87o9ciapdf.fsf@gmx.de> References: <837f6z9a4x.fsf@gnu.org> <87zhwguskw.fsf@gmx.de> <83fty8ge50.fsf@gnu.org> <83efdsgcqv.fsf@gnu.org> <875zz3mcnu.fsf@gmx.de> <834lengq5f.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1538064849 27033 195.159.176.226 (27 Sep 2018 16:14:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2018 16:14:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 25214@debbugs.gnu.org, tom@tromey.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 27 18:14:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g5YvT-0006ul-1b for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2018 18:14:03 +0200 Original-Received: from localhost ([::1]:37459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5YxZ-0001s6-4n for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2018 12:16:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5YxS-0001ry-FT for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2018 12:16:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5YxO-0001kX-4O for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2018 12:16:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52548) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g5YxO-0001kP-0C for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2018 12:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g5YxN-0004an-Nr for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2018 12:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Sep 2018 16:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25214-submit@debbugs.gnu.org id=B25214.153806493317613 (code B ref 25214); Thu, 27 Sep 2018 16:16:01 +0000 Original-Received: (at 25214) by debbugs.gnu.org; 27 Sep 2018 16:15:33 +0000 Original-Received: from localhost ([127.0.0.1]:56806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g5Ywv-0004a1-9g for submit@debbugs.gnu.org; Thu, 27 Sep 2018 12:15:33 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:55171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g5Ywt-0004Zm-J1 for 25214@debbugs.gnu.org; Thu, 27 Sep 2018 12:15:32 -0400 Original-Received: from detlef.gmx.de ([79.140.120.188]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LgZ7h-1fQmks3S1V-00nzwM; Thu, 27 Sep 2018 18:15:12 +0200 Original-Received: from detlef.gmx.de ([79.140.120.188]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LgZ7h-1fQmks3S1V-00nzwM; Thu, 27 Sep 2018 18:15:12 +0200 In-Reply-To: <834lengq5f.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Sep 2018 11:34:36 +0300") X-Provags-ID: V03:K1:gyjZUTZ1MytKsVfA4dDMyCQba5uiOu+5yEbSCBG1ctaqsWD5qwT 69wA0iYBs96WQlL+9/Iq4WG8/xXtsg/2MXj8C7+qeMf0ghE25+IdsMdf2Arh0Rd1gjYRmpn jBfRKOuoWYL9ewRKF0RcB3dIGwUEgp5O8mc03+TTzeMzvEHEEGT1eOsVRBP3h92Tm+feMPP 7/F9XGcpjNv2dDDVI2zwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:4+DBCPlpc0Q=:qxK947ZS0wWNa+/3DyG6p0 li5Hih9FxOlTP1WaEfjDwTw0YbyER4DMb879N4KsNkNfZwn1+dIQz6uVS7L6hIvxlbONRbypy HVdIhogtnE7IX/HqENoSUCCcYUJf2nTDyyKWqkularBA+rv8NuO2biESqM6Tn8HaBP+NhIdzS o/egVJV1Eo07f4LVszhASvVioug/bhsn1Q3lG0GThpwf0M9UomqPDGKmjRvzKUrM5ocTWIr2f XFMIyTxqhknLbo8JZV1HXVqMACyrcumjnKBrbqi1s0fGG5rRBtda4zkEfJd8zkea13CK4xn7F 3qsIeci8TJWygRgOcJEDSfhmHl5TSPbxnPvGjCcmzweV69D+5KxW0JWiOirTrsKe2gp7gtvOy ZzY4BLigF03+YwsG3AfUvTcO/4UwL2fWTA6owi7EBf6WhZbyfG7o/W1nMLX6vYEUWrddg5UXx gQyv2JoxF4lXh0BrP4frtG5K7+QK4r+dUubYpkzly2i9NEqyVoRpEnZACtH8RV2Dk0VxAxd7V 9tNyz9sohd/bScOvLLgb78KKKkpaLC3zK45U0l8B8gmjJ5aZLgJ23JVoeoqQ+PkV5ke4MPAMx WqSt+gWEr6zEhDn2vYNATRlkJASfqnZrXn3nuBrMECPxTtiFwfrls+8sYW1oRPTguKeEthpv+ dr0gvKQvh46GzteimkVO6fPTht1yGYVVzXq1trtmWmtjoMsjA3tTPj7r0oIDqHq44zCdF3oZU bqsNtKnyH+p/CJjO0K2yMhVWgUA3iVy8VVyNGa9WybA+bdERwAemAQvUKxiZuWYqnjB3fVFW X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:150717 Archived-At: Eli Zaretskii 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.