From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Wed, 29 Aug 2018 00:05:08 +0200 Organization: my virtual residence Message-ID: <87lg8qqh9n.fsf@himinbjorg.adminart.net> References: <838t59j821.fsf@gnu.org> <83a7phdl7r.fsf@gnu.org> <61492e7f622303d02405bedbe65fabae@webmail.orcon.net.nz> <83pnybdaer.fsf@gnu.org> <837ekicw7i.fsf@gnu.org> <877ekiierh.fsf@himinbjorg.adminart.net> <834lflb2fj.fsf@gnu.org> <83h8jk9l41.fsf@gnu.org> <8336v2994c.fsf@gnu.org> <83bm9q6x7v.fsf@gnu.org> <874lfi863s.fsf@himinbjorg.adminart.net> <83va7x5guc.fsf@gnu.org> <871sakl97g.fsf@himinbjorg.adminart.net> <8336uz6e8e.fsf@gnu.org> <877ekbego9.fsf@himinbjorg.adminart.net> <83mut73vau.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535494084 11809 195.159.176.226 (28 Aug 2018 22:08:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Aug 2018 22:08:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: psainty@orcon.net.nz, gazally@runbox.com, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 29 00:07:59 2018 Return-path: Envelope-to: ged-emacs-devel@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 1fum9W-0002vx-RK for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 00:07:59 +0200 Original-Received: from localhost ([::1]:40201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fumBd-0003Ym-35 for ged-emacs-devel@m.gmane.org; Tue, 28 Aug 2018 18:10:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fumBS-0003YK-PZ for emacs-devel@gnu.org; Tue, 28 Aug 2018 18:09:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fumAe-00011K-2L for emacs-devel@gnu.org; Tue, 28 Aug 2018 18:09:09 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::5]:14295) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fumAF-0000Tv-VA; Tue, 28 Aug 2018 18:08:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1535494120; s=strato-dkim-0002; d=adminart.net; h=Sender:References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=c3WISgd8oK/Grx75LHxyqzV/rQ/I5NzzCADmHC9JzeA=; b=HufJPtxzkB3/U94s75OFZOOmAFs46TXGtvG5Z7u8VxS3yJZK2Ogk2D2862FxmmTK1f IU/+71DfGOQp8AKtq8NRZAIlh1sKOCnQA8kcEtqw8O5GaYE0NXUbW+kPY6RyAxuSgHrr wo7ZxLASCCYEzjvQMgWZmRd6xgLSZWdT1WzN45sD6mdVirJxmKqGEdByrdpG9Lsb43zO N+XACc0W2q8SM81ZHscybxUfVav01IrOSi/M7QMxLn674frreNWo421RX25aA6+/UYwx P97pT46Z1vF8DNp72RR7Pdvwpt5cnymdVoSMlFtJOdJTVKeJbw1XJ/Fofhyi2Xbcogdi txhg== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 43.21 DYNA|AUTH) with ESMTPSA id j020b1u7SM8T2GI (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Wed, 29 Aug 2018 00:08:29 +0200 (CEST) Original-Received: from lee by himinbjorg.adminart.net with local (Exim 4.90_1) (envelope-from ) id 1fumA0-0001e9-S9; Wed, 29 Aug 2018 00:08:28 +0200 In-Reply-To: <83mut73vau.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Aug 2018 08:38:17 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229029 Archived-At: Eli Zaretskii writes: >> From: hw >> Cc: psainty@orcon.net.nz, gazally@runbox.com, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org >> Date: Mon, 27 Aug 2018 21:46:30 +0200 >> >> >> When you don't want threads to have to fight over the mini-buffer, each >> >> thread needs its own. >> > >> > Not necessarily: we could serialize the interactions. >> >> Users still require sequentiality to be able to deal with them. > > Yes, but there's no way around that. > >> > It doesn't seem to solve the problem: Emacs still has to decide which >> > minibuffer to use when. And if you want to put that onus on the user, >> > then that same user could instead switch to thread N in the single >> > minibuffer we have now. >> >> true >> >> And if you want neither Emacs to decide which prompts to interrupt the >> user with, nor let the user decide which prompts to deal with, you're >> kinda out of options. > > I'd prefer Emacs to decide that. I think Emacs might need at least some help from the user to make the right decision. Imagine serializing requests and presenting them to users with the right amount of sequentiality and historical context was already solved. What is Emacs supposed to do with requests after I start using it for programming and tell it that I am in do-not-disturb-mode? That mode means that I do not want to be disturbed by any prompt which is not directly related to what I'm currently doing, i. e. it's ok for Emacs to ask me for a file name right away when I press C-x C-f. It is definitely not ok to prompt me "FOO (y or n)" because Emacs is still copying or deleting files and wants to know something. I'd look into the progress of that some time later, or the next day maybe. It is also not ok for gnus to change the size of the mini-buffer or to ask me for a password when it automatically checks for new mail every now and then. Since there is no such thing as "a foreground", Emacs has no idea what I'm doing and no way to decide which requests it may allow to reach me and which ones not. It might help if I could qualify them so I can tell Emacs which classes of requests to allow and which ones not. Or it needs to queue them all. > My point above was that having several minibuffers doesn't solve the > basic problem, yes, I agree > which is: how should Emacs decide which of the threads' prompts gets > submitted to the user at any given time. When we solve that basic > problem, we could talk about the details like whether this happens in > the same minibuffer or in several. If Emacs shall be allowed to control the users in such a manner, it should always forward those requests the users want to currently deal with and withhold the ones they do not want to see :) How does Emacs figure out what a user currently wants to deal with? The user could help Emacs by going into the do-not-disturb-mode and giving it an adjustment period of, say, 10 seconds. During these 10 seconds, the user does nothing, and Emacs does not create any new threads and does not forward any requests. After that, Emacs forwards only those requests that have come up after the adjustment period and have been created by threads that were created after the adjustment period and, if they were created by other threads, the threads creating them must not have been created before the beginning of the adjustment period. This is probably a retarded idea which sucks, but it is a kind of way, time based, to figure out what the user is currently doing. But it would allow Emacs to prompt me right away for a file name when I want to visit one, which is what I would want. While the user is not in do-not-disturb-mode, it doesn't matter which prompt is forwarded first. It could be the oldest one, a random one or the newest one, maybe depending on which the user prefers. >> > Then the problem becomes how to manage that queue, and which part of >> > Emacs will do that. We are back to the same issue, just in a slightly >> > different form. >> >> Aren't the threads already managed in some way? > > No, not really. There's a single global lock and a race to grab it > when it becomes released by whatever thread was holding it. How is being decided for how long the most a thread can stall the others? What information is available when a thread is created? >> The queue would provide the historical context, and the user dealing >> with queue-entry X would implicitly and transparently switch to >> thread N. > > Placing that onus on the user is indeed one solution, but I still hope > we could do better. There are still problems even with such "manual" > switching: e.g., a background thread will typically run between 2 key > strokes of user's typing, which could be typing at the prompt of > another thread. So a background prompt may request to be serviced in > the middle of typing a key sequence, and it isn't clear what to do > then. hm Yeah it would suck if was prompted for FOO instead of for a file name when I wanted to visit a file. >> >> What you seem to think you must do --- grant an arbitrary thread access >> >> to the mini-buffer --- is what you *must not* do. >> > >> > But in that case everything becomes sequential again, and we gained >> > nothing by introducing concurrency into Emacs. >> >> The queue circumvents this: it would allow to present sequentiality (by >> historical context and perhaps by grouping all requests by the operation >> they are involved with) to the user while the execution of threads can >> remain serialized. > > Maybe I misunderstood what you proposed, but I thought that a request > gets removed from the queue when its thread finishes its job and > exits. If this is indeed what you meant, then we would have lost > concurrency. A request would be removed from the queue when it has been served (answered) by the user. How would a thread that needs to wait for the answer finish its job before it has been given the very answer it needs to finish? There wouldn't be much point in allowing threads that need to wait for an answer to stall others. The others could still run. >> Emacs could even assume the possible answers to a prompt and perform the >> actions resulting from the answers in some cases so that when the user >> makes a decision, the result is already available and the one not needed >> can be discarded :) > > I don't think this is possible in practice. We usually ask the user > questions for which only the user knows the answers. While (query-replace) is waiting for the user to answer its prompt, Emacs could anticipate the possibility that the user is going to perform all the possible replacements (after verifying only a few) and create a version of the buffer in which all replacements have been performed. Now when the user actually does what Emacs anticipated, it switches the buffers so the user doesn't need to wait for the replacements to be performed (assuming that would be faster than doing the replacements, for the sake of this example).