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:51:24 +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="0000000000008d59c4056cf74d3b" X-Trace: blaine.gmane.org 1527184183 27894 195.159.176.226 (24 May 2018 17:49:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 May 2018 17:49:43 +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:49:39 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 1fLuMr-00077v-Sd for ged-emacs-devel@m.gmane.org; Thu, 24 May 2018 19:49:38 +0200 Original-Received: from localhost ([::1]:40079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLuOy-0005Wx-Rs for ged-emacs-devel@m.gmane.org; Thu, 24 May 2018 13:51:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLuOr-0005Wf-Jk for emacs-devel@gnu.org; Thu, 24 May 2018 13:51:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLuOq-0002kS-8y for emacs-devel@gnu.org; Thu, 24 May 2018 13:51:41 -0400 Original-Received: from mail-ot0-x234.google.com ([2607:f8b0:4003:c0f::234]:46440) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fLuOo-0002jV-LZ; Thu, 24 May 2018 13:51:38 -0400 Original-Received: by mail-ot0-x234.google.com with SMTP id t1-v6so2954061ott.13; Thu, 24 May 2018 10:51:38 -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=gnl9+/yCB7o506VeaIulRppRL2FH24lCp+j+eDXrM3g=; b=qTN+Wys+VbTUaM3hH3gAKFt/3Vi2PzvJ64r2t7BccvoAMW2OeG5QzLkqUSG3Xo3UCI kX+vga+f+/OFFZIQXmHtWsNkmT+Z8O+rTYdG5h52wAtvEvY7xpVrAPjCCSOfYZnMPcFf hg0h16Th+ZUoeQ9gD1dq1ypnhh8/tkY8YSxvMZz4XLcnP9KbXg1Uy3tYL6+KYVi96f7o PKQKxKX0mvJJ7j4IWnDy7BoIqx7LFXEEoHW0BAbAdo+y6jdleAgkNCWsrWe+rgHxuAQT qhJiVHciIK8+lYaeHay2WihlxIBbUWoU9D/NMbxVFuZ0bObzRrmyiZ6AsjQwT1fqJhmx Wp2g== 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=gnl9+/yCB7o506VeaIulRppRL2FH24lCp+j+eDXrM3g=; b=a4RgimLIYFQE7qOzagJ/G9M4cG4B8N3o8xZ/i2JKyUlK4odqxGDO4cAl2bL68rLVx9 YGbGhFU7YcaUsomS6CeEsliUdv3/60lyGBDLWwuS4An9mWeE6tY8HqjQggMbbw8XG8P4 jsufViezZNhsgesCenbylngZa+BgTWqinXPJwQMSEOrtUwOYB2YAQNFn0M+iB3Y6rbhu YIW3UQtOJo0WFSIYfwWZDrwdRb+gRiP7ATY1szzhRL8aXK826XqtC0mWuaaFFCQarhYM hQoXN9Nm46juaWFr2Wqm0y7H2uJfuQAOtIB3tmskIFPcTGBJ5/SKkr0JRN/i9xSs88li RL3A== X-Gm-Message-State: ALKqPwc7Hy1bi32eJ1wzXba03a/PeMYYG+AbTaaidndKTK8t6z+kBpr+ nJQ2gjBrcQN7boVTAI2v6YXczLK+evG0aoWk+uj01Q== X-Google-Smtp-Source: AB8JxZpo7Sa2Q/q6cIw7c0RnXC14m3+pWpwcOPD3GBzC6a9vkZAOJM6i7I9JDhSJlsLAe/XbwxGqcZFLNB1p/7nJKkw= X-Received: by 2002:a9d:440b:: with SMTP id u11-v6mr4971470ote.276.1527184297382; Thu, 24 May 2018 10:51:37 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c0f::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:225672 Archived-At: --0000000000008d59c4056cf74d3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philipp Stephani schrieb am Do., 24. Mai 2018 um 19:46 Uhr: > > > >> > 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/Conceptua= l/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/d= oc/uid/10000057i-CH12-123351-BBCFIIEB > , > https://developer.apple.com/documentation/appkit/nsapplication/1428710-po= stevent?language=3Dobjc, > and > https://developer.apple.com/documentation/objectivec/nsobject/1414900-per= formselectoronmainthread?language=3Dobjc > . > > What's the "input thread" in the Windows implementation? At least on macO= S > 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) shoul= d > become background threads. > However, the documentation also says "The main thread is the one blocked in the run method of NSApplication", which seems to indicate that the "main" thread doesn't actually have to be the same thread that the main function runs in. --0000000000008d59c4056cf74d3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Do., 24. Mai 2018 um 19:46=C2=A0Uhr:


> 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.


What's the "input thread" in the Windows implementatio= n? At least on macOS the UI thread (i.e. the thread that creates windows an= d handles events) must be the main thread, which means the Lisp interpreter= thread(s) should become background threads.=C2=A0

However, the documentation also says "The ma= in thread is the one blocked in the run method of NSApplication", whic= h seems to indicate that the "main" thread doesn't actually h= ave to be the same thread that the main function runs in.=C2=A0
=
--0000000000008d59c4056cf74d3b--