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: Mon, 27 Aug 2018 18:53:47 +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> <87bm9qbqtd.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bec0810574688a00" X-Trace: blaine.gmane.org 1535367948 22900 195.159.176.226 (27 Aug 2018 11:05:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 11:05:48 +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 Mon Aug 27 13:05:43 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 1fuFL5-0005rP-AR for ged-emacs-devel@m.gmane.org; Mon, 27 Aug 2018 13:05:43 +0200 Original-Received: from localhost ([::1]:52482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuFNB-0001Em-29 for ged-emacs-devel@m.gmane.org; Mon, 27 Aug 2018 07:07:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuFMz-0001Ch-Rj for emacs-devel@gnu.org; Mon, 27 Aug 2018 07:07:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuF9k-0006Il-C8 for emacs-devel@gnu.org; Mon, 27 Aug 2018 06:54:01 -0400 Original-Received: from mail-it0-x22a.google.com ([2607:f8b0:4001:c0b::22a]:36199) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fuF9i-0006Hf-0b; Mon, 27 Aug 2018 06:53:58 -0400 Original-Received: by mail-it0-x22a.google.com with SMTP id u13-v6so1742799iti.1; Mon, 27 Aug 2018 03:53:57 -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=FIVOnUNEDOTHqDXb2DL0Te5kqO8z1G5I4so3aebVRMI=; b=sPtGimMTayYYY2ntvSJLuLffhzoq1KbXTZlrxsYQ7UyszbxD7NSJE3cQ294m7CVZMv MjK/TxGUopaMnAkGZ8NbA1BTW3pCxkE9LPTLu6Exi6BGWlNMljCGqELx29TMBKpekxsK qXFvYsNLojQVYnkJsOR1bUi4S/b+20Tz9N9zYizMLwpgpBjA3S0I+NTiOlx+RfBQECVM rvczhMQrbM7ZVCiDrEoelrAs/4NsGRElF2CADQ7WAREhk3Jant5+yxh3HzuSpQniP1Zz 63sExQ+Wc1aYD8ld1C6Ul4RxEGiKXaBpprmsxSYudZDFgwDXTck3byb7uafBHsHGXkcf bmKg== 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=FIVOnUNEDOTHqDXb2DL0Te5kqO8z1G5I4so3aebVRMI=; b=KUnlvIATCxszi4zi65eqtfW2pb3z8/nW7UVUUR3fAvr4hSCe4bcXqwIMardgbcxNFM cflMloagOwFE5xJJEIm220ONLKAVa+zWFG9A2aZtlvyll7g+m6Awxw7jreJ52N7pC+f/ T8FYGSM7V/QNkKD0+wx8Z47WMp+5AmeLuYihwIZ9VVQ+qT30NdyMym51cmlCE9LG8qwY 84rnmhCnRQivGNMomJt9s2W3B1zbcxWOPVP0e7cK8cXb6+aafJVdCjka4q/3+p1kSc53 RjAlyhcnoqz3KR2p1tlhWQTQph4f4RIkzLegFNLDXO0txRKc20ilx13rbFt70YdHESff 9aEw== X-Gm-Message-State: APzg51CfU4Olpp5Ee8wXpAw3ahyLOaxW0lKxp5nXBaCscAeOX0npSEei yfwpbVFuKmPcdW+etUdASFhy9RgVYNDJPnPyzKc= X-Google-Smtp-Source: ANB0VdbCpGjoJVd0C86OkSVuCuehwLW4kRGMIcgVh6UZT6gR1gAwdQNW/WRboLl7Mll0oUDKQKFk4BSzyHAy0PXw7CE= X-Received: by 2002:a24:6b0e:: with SMTP id v14-v6mr6491402itc.90.1535367236729; Mon, 27 Aug 2018 03:53:56 -0700 (PDT) In-Reply-To: <87bm9qbqtd.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22a 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:228966 Archived-At: --000000000000bec0810574688a00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 25 Aug 2018 at 19:58, Michael Albinus wrote: > Elias M=C3=A5rtenson writes: > > Hi Elias, > > > 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. > > But then you must force everybody to use the > `call-with-prompt-interaction' function. Well, yes. Although I'd expect new code to use =E2=80=98with-prompt-interac= tion=E2=80=99. > Doesn't it suffice to advice > `mutex-lock' and `mutex-unlock'? In your advice code you could check, > whether MUTEX is equal to `interaction-mutex'. > That would be possible, but looks rather ugly to me. Also, the fact that a mutex is used should be an implementation detail not visible to the user of the API. Having a dedicated function/macro pair for this is much cleaner. Regards, Elias --000000000000bec0810574688a00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 25 Aug 2018 at 19:58, Michael Albinus <michael.albinus@gmx.de> wrote:
Elias M=C3=A5rte= nson <lokedhs@gma= il.com> writes:

Hi Elias,

> May I propose that the murex be hidden behind a function and a macro?<= br> > 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)
>=C2=A0 =C2=A0(call-with-prompt-interaction `(lambda ()=C2=A0 ,@body)))<= br> >
> (defun call-with-prompt-interaction (fn)
>=C2=A0 =C2=A0(with-mutex (interaction-mutex)
>=C2=A0 =C2=A0 =C2=A0(funcall fn)))
>
> This would allow advices to be applied to the
> call-with-prompt-interaction function.

But then you must force everybody to use the
`call-with-prompt-interaction' function.

Well, yes. Although I'd expect new code to use =E2=80=98with-prompt-i= nteraction=E2=80=99.
=C2=A0
Doesn't it suffice to advice
`mutex-lock' and `mutex-unlock'? In your advice code you could chec= k,
whether MUTEX is equal to `interaction-mutex'.
That would be possible, but looks rather ugly to me. Also, the = fact that a mutex is used should be an implementation detail not visible to= the user of the API. Having a dedicated function/macro pair for this is mu= ch cleaner.

Regards,
Elias
=
--000000000000bec0810574688a00--