From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Should this package be included into the NS port? Date: Thu, 24 May 2018 19:46:19 +0200 Message-ID: References: <20180515183631.GB27909@breton.holly.idiocy.org> <20180518193632.GA31241@breton.holly.idiocy.org> <20180519103329.GB31853@breton.holly.idiocy.org> <83k1rucs15.fsf@gnu.org> <20180523212129.GB36578@breton.holly.idiocy.org> <83h8mxau22.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000059dc3f056cf73b55" X-Trace: blaine.gmane.org 1527183888 5803 195.159.176.226 (24 May 2018 17:44:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 May 2018 17:44:48 +0000 (UTC) Cc: Alan Third , nick@tenpoint.co.nz, emacs-devel@gnu.org, georgedp@orbitalimpact.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 24 19:44: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 1fLuI6-0001Ml-C3 for ged-emacs-devel@m.gmane.org; Thu, 24 May 2018 19:44:42 +0200 Original-Received: from localhost ([::1]:40041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLuKD-0003C2-Bj for ged-emacs-devel@m.gmane.org; Thu, 24 May 2018 13:46:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLuJw-0003BI-H2 for emacs-devel@gnu.org; Thu, 24 May 2018 13:46:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLuJv-0007Mt-5a for emacs-devel@gnu.org; Thu, 24 May 2018 13:46:36 -0400 Original-Received: from mail-ot0-x232.google.com ([2607:f8b0:4003:c0f::232]:32780) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fLuJt-0007Jw-AM; Thu, 24 May 2018 13:46:33 -0400 Original-Received: by mail-ot0-x232.google.com with SMTP id l22-v6so2965409otj.0; Thu, 24 May 2018 10:46:33 -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=JSxQOiR+PcRWmv/brtKDwiTQ/ODy9722O1DkLsvEw8I=; b=WHkqDV4LuREhoWtmPkoH+M+GmRrRjJjyefaEwbrUcNs/RR+DIXebhMeFkAb12Nv3pD A21adY3FSafyJI8tDECVdwwzTZvNeE3xLCfioiwIF5I8sf68Qf5xOPv3OeaK5UbxalVG vzNTKMtUBwzEAXQ5Fg5BRiybJFumqRRlIh41+B4um2iTQNaMUyfxO/ykqs72gjMEh4MC wx1g0Ai9yHsMDaIIY35kg0PjYkAiGBrKElkINqniwWrf+nyftqo2RnmsYmFVjloY+BfA 1i97oOZZdimvEW2H/JwrmclPVoDKueOKh+HGZlwaq8qEkI1VApO+6VYfTydEciHHECjH 6lEQ== 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=JSxQOiR+PcRWmv/brtKDwiTQ/ODy9722O1DkLsvEw8I=; b=oXycaQiBk/t+9hicHIbap63vQR/wCCW26sivz54RdHoUjYblFq9zwEe7aWhVDIEAMH hcQ0EyJY25/27AfxOq0rEEaLKKPVg80tQNMCzYQeB7DDTal2YFkjf3PvexGb+1xObOCv 5h29EEmpQp8KcVeH4hLYXr1fHn+EOlfQn42vUqT1FJbK0f49Ynj6i0xWRibliyYCCGez 9KaSYXjD2p8n4n+AFwJ8ciuAqy1b0N6/zgdoi9ogS9eoXF2EexIckKKPUs2PomRgS2jO LO5EFPYdcraRynFBhA6MWlTQ1acbWcvLaCwTi3dJquVlBkRx13Q96AbBfDJYTQxQDsst PciA== X-Gm-Message-State: ALKqPwcnaYPwm22/4zvOuCZW/fLu1lnUiL+HodllKVFrK3bMUfqmCPyp 34gtUJJxeO/9Wl8Jy4M4iGHZDEgTxfydnkwcigqawA== X-Google-Smtp-Source: AB8JxZqr1uQvgF0m3+zvmaGiGJzhlE2kiVVxgWEFBKQcsILKPtQ9NJOgfHixcUld0j6z+bxheuY6RoC7axDXvu6OI6M= X-Received: by 2002:a9d:440b:: with SMTP id u11-v6mr4961310ote.276.1527183992016; Thu, 24 May 2018 10:46:32 -0700 (PDT) In-Reply-To: <83h8mxau22.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c0f::232 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:225671 Archived-At: --00000000000059dc3f056cf73b55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eli Zaretskii schrieb am Do., 24. Mai 2018 um 18:38 Uhr: > > Date: Wed, 23 May 2018 22:21:29 +0100 > > From: Alan Third > > Cc: Nick Helm , emacs-devel@gnu.org, > > georgedp@orbitalimpact.com, monnier@iro.umontreal.ca > > > > The main problem I have is things coming in the opposite direction. I > > don=E2=80=99t know if W32 is the same, but we can only run GUI related = code in > > the main thread. > > What do you mean by "GUI code" here? > Code that interacts with the windowing system. > > > If we separate the Lisp thread and the NS run loop thread, then code > > called from Lisp can=E2=80=99t directly interact with the NS GUI code, = it > > has to be dispatched to the NS run loop thread. > > The w32 build has a similar problem, and it solves it by setting up > message queue between the main and the input threads. Messages are > sent between the two threads when needed, and the Windows native > messages are used in the opposite direction. So when one thread needs > something done by the other thread, it sends the appropriate message, > waits for a response, then continues (and sometimes it doesn't have to > wait for any response, it depends on the case). > > Can NS use some similar machinery? > > Most likely yes (because UI toolkits always work that way). The to-be-written GTK+ terminal should use the same mechanism. See https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/= Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc= /uid/10000057i-CH12-123351-BBCFIIEB , https://developer.apple.com/documentation/appkit/nsapplication/1428710-post= event?language=3Dobjc, and https://developer.apple.com/documentation/objectivec/nsobject/1414900-perfo= rmselectoronmainthread?language=3Dobjc . What's the "input thread" in the Windows implementation? At least on macOS the UI thread (i.e. the thread that creates windows and handles events) must be the main thread, which means the Lisp interpreter thread(s) should become background threads. --00000000000059dc3f056cf73b55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Do., 24. Mai 2018 um 18:38=C2=A0Uhr:
> Date: Wed, 23 May 2018 22:21:29 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Nick Helm <nick@tenpoint.co.nz>, emacs-devel@gnu.org,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0georgedp@orbitalimpact.com, monnier@iro.umontreal.ca
>
> The main problem I have is things coming in the opposite direction. I<= br> > don=E2=80=99t know if W32 is the same, but we can only run GUI related= code in
> the main thread.

What do you mean by "GUI code" here?

Code that interacts with the windowing system.
=C2=A0

> If we separate the Lisp thread and the NS run loop thread, then code > called from Lisp can=E2=80=99t directly interact with the NS GUI code,= it
> has to be dispatched to the NS run loop thread.

The w32 build has a similar problem, and it solves it by setting up
message queue between the main and the input threads.=C2=A0 Messages are sent between the two threads when needed, and the Windows native
messages are used in the opposite direction.=C2=A0 So when one thread needs=
something done by the other thread, it sends the appropriate message,
waits for a response, then continues (and sometimes it doesn't have to<= br> wait for any response, it depends on the case).

Can NS use some similar machinery?


Most likely yes (because UI toolkits a= lways work that way). The to-be-written GTK+ terminal should use the same m= echanism.


--00000000000059dc3f056cf73b55--