From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Elias_M=C3=A5rtenson?= Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Fri, 24 Aug 2018 23:41:40 +0800 Message-ID: References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> <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> <876000c7ko.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e4d9890574303619" X-Trace: blaine.gmane.org 1535125205 14946 195.159.176.226 (24 Aug 2018 15:40:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2018 15:40:05 +0000 (UTC) Cc: hw@adminart.net, Richard Stallman , Gemini Lasswell , psainty@orcon.net.nz, emacs-devel , emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, Eli Zaretskii To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 24 17:40:00 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 1ftEBs-0003dy-Bn for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 17:40:00 +0200 Original-Received: from localhost ([::1]:42283 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftEDt-0005Zv-IB for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 11:42:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftEDj-0005Zb-Ta for emacs-devel@gnu.org; Fri, 24 Aug 2018 11:41:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftEDj-0006wZ-2b for emacs-devel@gnu.org; Fri, 24 Aug 2018 11:41:55 -0400 Original-Received: from mail-it0-x234.google.com ([2607:f8b0:4001:c0b::234]:37987) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ftEDg-0006u9-KL; Fri, 24 Aug 2018 11:41:52 -0400 Original-Received: by mail-it0-x234.google.com with SMTP id p129-v6so2490902ite.3; Fri, 24 Aug 2018 08:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BEGLhVjem3urJ8ft+XHl1VsWEj2inY27J2NHO1EAW7E=; b=QBI3McOSSbOxr1puFYSW4WAI1ybv9ds1uM70qlHDRLkqZuKWWDSqrnLShY2wepivN5 0AfHFv5ivmJS1qHrZWcyQNqOnluratlr6jhafpXkC0nvL7d12WLkg7qSh6tF+kP7ReHJ y6hCKdbPwv8mkcjV8Zn+K2yJnxGNCX6WhFfdlekwtRx3Wqqrw5OYGvNt6w8KedNgnc1v a2dGuB33n/gDNL5oQsPKemxO2FpOu2ZfyNRYmgN3WgCreqjvhDiF9UQXNiA1S+ASUIay FcUWP5MgPSzlb2nuPYgFDKvGQLH+YWzZmAgDLeDaXFfuTXcXcfYzQL7kZ7QWZ1JzXsYR dH8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BEGLhVjem3urJ8ft+XHl1VsWEj2inY27J2NHO1EAW7E=; b=VXL98DO8YvLIIR96sV/bZxM3NQbriKWhdXLIE89FjqIN/kMFsH7oOtTR2RiEG55C9Z 9XHNj9czhJU3xU12uTNKcDJlTojJDk/jIENAVVo68UcrYqEYnUYU4DjRwKlGts6Dmz34 zryw2idQzbDpeyQJHGqW6i+LzYd6wGc59LJDXWbFYrsZJ1T+4SI++m/QW8KzM51VYZrO jjHievUzRn00nwPvj2398zBxMKgPS5Ob/NcSgbI5vr74ly9zhYNIPHtTnZKRlCq1fvAQ d0V6/Eh1MqAu8ETBcymjXr/pwdcPXU/29MdG0JutIq9lpjhhTrGUYJpJEUqbwMzvxcln DMsw== X-Gm-Message-State: APzg51D+BTdzzcNweI3udpdq+ViuHMtXpNNa/oBCUl6nA4aY33fW0cPP tORjGH2jesRUMmGeVeQp9IQN+mkK6JREahMIkrY= X-Google-Smtp-Source: ANB0Vda6oI7C1Gx9OenN4RLBniNCMzXsIw+e6mO2qV/QBDgI8Xge7yHNhj0JOHaD//Lree+T0Qu7+BWP3hN63MFZ2ZM= X-Received: by 2002:a02:778d:: with SMTP id g135-v6mr1764405jac.90.1535125311770; Fri, 24 Aug 2018 08:41:51 -0700 (PDT) In-Reply-To: <876000c7ko.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::234 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:228871 Archived-At: --000000000000e4d9890574303619 Content-Type: text/plain; charset="UTF-8" On Fri, 24 Aug 2018 at 19:46, Michael Albinus wrote: > Eli Zaretskii writes: > > > The idea expressed by several people is that once you start > > interacting with some thread's prompt, the other threads are locked > > out of interaction, until the interacting thread is done with the > > series of prompts that allow it to go on with its business. > > Yes. The simplest locking mechanism I could imagine is a mutex locking > such interactions. This must be used for every > echo-a-prompt-and-read-the-answer interaction by default (we shall > determine all low-level cases). And it shall be a predefined, documented > mutex, like `interaction-mutex'. > May I propose that the murex be hidden behind a function and a macro? The purpose of this would be to allow for the function to adviced by libraries that want to do something special. Something like this: (defmacro with-prompt-interaction (&body body) (call-with-prompt-interaction `(lambda () ,@body))) (defun call-with-prompt-interaction (fn) (with-mutex (interaction-mutex) (funcall fn))) This would allow advices to be applied to the call-with-prompt-interaction function. Regards, Elias --000000000000e4d9890574303619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 24 Aug= 2018 at 19:46, Michael Albinus <michael.albinus@gmx.de> wrote:
Eli Zaretskii <e= liz@gnu.org> writes:

> The idea expressed by several people is that once you start
> interacting with some thread's prompt, the other threads are locke= d
> out of interaction, until the interacting thread is done with the
> series of prompts that allow it to go on with its business.

Yes. The simplest locking mechanism I could imagine is a mutex locking
such interactions. This must be used for every
echo-a-prompt-and-read-the-answer interaction by default (we shall
determine all low-level cases). And it shall be a predefined, documented mutex, like `interaction-mutex'.

Ma= y I propose that the murex be hidden behind a function and a macro? The pur= pose of this would be to allow for the function to adviced by libraries tha= t want to do something special. Something like this:

(defmacro with-prompt-interaction (&body body)
=C2=A0 (cal= l-with-prompt-interaction `(lambda ()=C2=A0 ,@body)))

<= div>(defun call-with-prompt-interaction (fn)
=C2=A0 (with-mutex (= interaction-mutex)
=C2=A0 =C2=A0 (funcall fn)))

This would allow advices to be applied to the call-with-prompt-inte= raction function.

Regards,
Elias
--000000000000e4d9890574303619--