From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Callbacks from modules Date: Thu, 26 Nov 2015 18:44:47 +0000 Message-ID: References: <83vb8otxhf.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1130cd24af3132052575f88c X-Trace: ger.gmane.org 1448563562 24953 80.91.229.3 (26 Nov 2015 18:46:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 18:46:02 +0000 (UTC) Cc: darthandrus@gmail.com, dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 26 19:45:54 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a21YA-0007WR-94 for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 19:45:46 +0100 Original-Received: from localhost ([::1]:52795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a21YC-0000yk-7y for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 13:45:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a21XQ-0000CI-P7 for emacs-devel@gnu.org; Thu, 26 Nov 2015 13:45:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a21XP-0002xV-OI for emacs-devel@gnu.org; Thu, 26 Nov 2015 13:45:00 -0500 Original-Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:35192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a21XN-0002wt-SU; Thu, 26 Nov 2015 13:44:58 -0500 Original-Received: by wmuu63 with SMTP id u63so31282941wmu.0; Thu, 26 Nov 2015 10:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Vt+piYr2k6txydRmzbTjbo0DDAqQ9YADv+DBVWZjnsM=; b=ib2Wtfl5el/oJLmI2lmY4d9G/N7RKUGbvgbWyKQACDs7jccIZrWd4TeNL78bGAjTQr RYc3WDjq2FuJWVGxx3yFh+Qlp5EoVk4R3v/xXfQesW2AA4vkkFz3yj6lsyc6vSmtncAc OyzCx+11Id2ek3y7fk6XbgPNy57iRKYda/c1Yk66RAYeb0Jq9jGNZ7FLoLwMmPC5p6L6 0HAHBlpGp18wRTNinjMFzDOsqhRQolWIrZUIbkcde42s5LG5tC6baIwW6LQ6Omxs3EuL t1M9YDyY9BXnADEV/ygiTBUU+jdiTw5NnUOjCrUzCMtCkjfcfokXeyjFG2HNq8S4sK9N bE9Q== X-Received: by 10.194.116.170 with SMTP id jx10mr23795456wjb.166.1448563497183; Thu, 26 Nov 2015 10:44:57 -0800 (PST) In-Reply-To: <83vb8otxhf.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195309 Archived-At: --001a1130cd24af3132052575f88c Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Do., 26. Nov. 2015 um 19:41 Uhr: > > From: Philipp Stephani > > Date: Thu, 26 Nov 2015 18:16:13 +0000 > > Cc: Eli Zaretskii , Daniel Colascione > > > > There are two major issues with allowing callbacks at arbitrary times, > which > > need to be discussed and resolved first. The first is that such a > facility > > would change the execution model of Emacs in a quite fundamental way. > Right now > > all user-defined code inside the Emacs process gets run through a path > under > > the control of Emacs, either as a response to an input event, or a > timer, or a > > process filter etc. Adding a facility to run module code from arbitrary > > callbacks would remove this invariant, which can have global effects on > Emacs. > > I don't even understand what is meant by "arbitrary callbacks". If > they are called in the context of a separate thread, we will not allow > them to run. > Yes, but there are other possibilities. For example, modules can create additional windows in the main thread and install windows procedures pointing to them. Such window procedures currently cannot communicate with Emacs. > > IOW, such arbitrary callbacks need to run in the C land, and > communicate with Lisp via timers. In the future, we might add > facilities that would allow a module register a file descriptor > through which events could flow into the Emacs event queue. But that > is not yet available, and I'm not sure we'd want to allow it. > > I agree. --001a1130cd24af3132052575f88c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Do., 26. Nov. 2015 um 19:41=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Thu, 26 Nov 2015 18:16:13 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, Daniel Colascione <dancol@dancol.org>
>
> There are two major issues with allowing callbacks at arbitrary times,= which
> need to be discussed and resolved first. The first is that such a faci= lity
> would change the execution model of Emacs in a quite fundamental way. = Right now
> all user-defined code inside the Emacs process gets run through a path= under
> the control of Emacs, either as a response to an input event, or a tim= er, or a
> process filter etc. Adding a facility to run module code from arbitrar= y
> callbacks would remove this invariant, which can have global effects o= n Emacs.

I don't even understand what is meant by "arbitrary callbacks"= ;.=C2=A0 If
they are called in the context of a separate thread, we will not allow
them to run.

Yes, but there are other p= ossibilities. For example, modules can create additional windows in the mai= n thread and install windows procedures pointing to them. Such window proce= dures currently cannot communicate with Emacs.
=C2=A0

IOW, such arbitrary callbacks need to run in the C land, and
communicate with Lisp via timers.=C2=A0 In the future, we might add
facilities that would allow a module register a file descriptor
through which events could flow into the Emacs event queue.=C2=A0 But that<= br> is not yet available, and I'm not sure we'd want to allow it.


I agree.=C2=A0
--001a1130cd24af3132052575f88c--