[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can we go GTK-only?

From: YAMAMOTO Mitsuharu
Subject: Re: Can we go GTK-only?
Date: Tue, 01 Nov 2016 17:22:10 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Mon, 31 Oct 2016 04:24:31 -0400, Ken Raeburn <address@hidden> said:

>> Cocoa (maybe also for GNUstep?) has a restriction that GUI events
>> must be processed in the main thread.  Probably the Lisp thread
>> also wants to be main, especially when we start it by a tty-only
>> session and then add a GUI session via multi-tty.

> Nothing comes to my mind that requires that the Lisp thread be the
> initial thread; I would think we could start a new thread for the
> main Lisp interpreter.  (At least in the X11 build, that should be
> fairly easily testable, too — just move *everything* we do from the
> initial thread to a new thread, and have the initial thread just
> wait around doing nothing.)

Indeed.  Then this is not a serious restriction for attaching a Cocoa
GUI terminal with multi-tty.  Detaching is easier if the GUI process
is separated (as far as I know, the only way for a Cocoa GUI
application to disconnect from the window server or Dock on macOS is
to terminate the application process), but this has nothing to do with
the "main thread restriction".

>> So we have to separate processes for GUI front-end and Lisp
>> back-end to support such situations, anyway.

> It might not be a bad way to go, if we can keep the interprocess
> communication efficient enough, but I don’t think it’ll be required.
> Even if we do that, some part of the main Emacs process needs to
> communicate with these multiple GUI processes, so do we wind up with
> multiple UI threads in the main process anyway?

You don't need multiple UI threads.  The overall shape wouldn't be
much different from the current one for communication with multiple
X11 servers.

                                     YAMAMOTO Mitsuharu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]