[Top][All Lists]

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

Re: Can we go GTK-only?

From: Eli Zaretskii
Subject: Re: Can we go GTK-only?
Date: Mon, 31 Oct 2016 17:54:30 +0200

> From: Ken Raeburn <address@hidden>
> Date: Sun, 30 Oct 2016 10:43:37 -0400
> Cc: address@hidden
> I wonder if we should let them run their event loops, in their own threads, 
> and 
> separate that from the non-GUI events like subprocesses and timers, and from 
> Lisp evaluation, as much as possible.  For that matter, some of the 
> subprocess 
> handling could probably use helper threads, like for TLS encryption and 
> decryption work.

Beware of asking for too much, because that would mean a complete
redesign, something that I think is impractical.  One problem with
having too much code in separate threads is that only the main thread
can call malloc/free, i.e. you cannot create/destroy objects in other
threads.  Another problem is calling QUIT: you need to switch to the
main thread before you do that, or else you will crash.  And there are
probably other limitations.

The w32 build uses a separate thread for receiving the window-system
events, so you might look there for some ideas that won't blow up the
basic MVC design of Emacs.  In a nutshell, the events received by the
w32 input thread are pushed onto a queue which is serviced by an
emulation of a socket-read hook, called from keyboard.c, like all the
other such hooks.

Of course, this doesn't help when the main thread is busy doing
something prolonged, because it then doesn't get to processing the
input events.

reply via email to

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