unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philipp Stephani <p.stephani2@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Alan Third <alan@idiocy.org>,
	nick@tenpoint.co.nz, emacs-devel@gnu.org,
	georgedp@orbitalimpact.com, monnier@iro.umontreal.ca
Subject: Re: Should this package be included into the NS port?
Date: Thu, 24 May 2018 19:51:24 +0200	[thread overview]
Message-ID: <CAArVCkT7k8SsEAss6vOFxbUtn78VDBoFvE3eZG=uogJCwRTE8g@mail.gmail.com> (raw)
In-Reply-To: <CAArVCkSFhrX0pRd=SZHLnu5MN0kjNQZq4_q_mOeW9tSNV51quw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Philipp Stephani <p.stephani2@gmail.com> 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’t 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-postevent?language=objc,
> and
> https://developer.apple.com/documentation/objectivec/nsobject/1414900-performselectoronmainthread?language=objc
> .
>
> 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.
>

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.

[-- Attachment #2: Type: text/html, Size: 2928 bytes --]

  reply	other threads:[~2018-05-24 17:51 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15  5:19 Should this package be included into the NS port? George Plymale II
2018-05-15 18:25 ` Stefan Monnier
2018-05-15 18:36   ` Alan Third
2018-05-16  2:48     ` George Plymale II
2018-05-18 19:36       ` Alan Third
2018-05-18 21:21         ` George Plymale II
2018-05-19  4:57           ` Nick Helm
2018-05-19 15:49             ` George Plymale II
2018-05-23  5:22               ` Nick Helm
2018-05-23 19:29                 ` George Plymale II
2018-05-19  9:50           ` Alan Third
2018-05-19 16:06             ` George Plymale II
2018-05-19 18:33             ` Stefan Monnier
2018-05-22  1:42               ` George Plymale II
2018-05-22  1:48                 ` Van L
2018-05-22 19:04                   ` Alan Third
2018-05-23  2:30                     ` Off Topic (was: Should this package be included into the NS port?) Van L
2018-05-23 20:43                       ` Alan Third
2018-05-24  1:27                         ` emacs-26.1-rc1: ./configure (was: Off Topic) Van L
2018-05-24  8:55                           ` emacs-26.1-rc1: ./configure Robert Pluim
2018-05-24 10:51                             ` Van L
2018-05-24 11:51                               ` Robert Pluim
2018-05-24 11:57                                 ` Van L
2018-05-24 23:47                               ` Van L
2018-05-22 19:15                 ` Should this package be included into the NS port? Alan Third
2018-05-22 20:09                   ` George Plymale II
2018-05-19  4:42         ` Nick Helm
2018-05-19 10:33           ` Alan Third
2018-05-19 11:51             ` Philipp Stephani
2018-05-19 16:52             ` George Plymale II
2018-05-23  4:55             ` Nick Helm
2018-05-23  5:11             ` Nick Helm
2018-05-23 15:26               ` Eli Zaretskii
2018-05-23 16:37                 ` Stefan Monnier
2018-05-23 17:23                   ` Eli Zaretskii
2018-05-23 21:21                 ` Alan Third
2018-05-24 16:37                   ` Eli Zaretskii
2018-05-24 17:46                     ` Philipp Stephani
2018-05-24 17:51                       ` Philipp Stephani [this message]
2018-05-24 18:14                       ` Eli Zaretskii
2018-05-16  2:44   ` George Plymale II
2018-05-17 22:13 ` George Plymale II
2018-05-18 18:50   ` Alan Third
2018-05-18 20:40     ` George Plymale II
2018-05-19  8:31     ` Michael Albinus
2018-05-19  4:29 ` Nick Helm
2018-05-19 15:38   ` George Plymale II
2018-05-29 21:29 ` George Plymale II
2018-05-29 21:42   ` Alan Third
2018-05-29 23:40     ` George Plymale II
2018-05-31 20:40       ` Alan Third
2018-06-01  1:58         ` Stefan Monnier
2018-06-02 18:31           ` George Plymale II
2018-06-02 19:39             ` Stefan Monnier
2018-06-02 20:11               ` Alan Third
2018-06-03  2:25                 ` Stefan Monnier
2018-06-02 18:26         ` George Plymale II
2018-06-02 16:45       ` Ryan Thompson
2018-06-02 17:22         ` Stefan Monnier
2018-06-02 18:56         ` George Plymale II

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAArVCkT7k8SsEAss6vOFxbUtn78VDBoFvE3eZG=uogJCwRTE8g@mail.gmail.com' \
    --to=p.stephani2@gmail.com \
    --cc=alan@idiocy.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=georgedp@orbitalimpact.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=nick@tenpoint.co.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).