Re: Can we go GTK-only?

[Eli Zaretskii <eliz@gnu.org>]

> Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Tue, 1 Nov 2016 13:17:01 -0700
> 
> > I was not talking about multithreading in general.  I was talking
> > specifically about Emacs, its coding practices, and its particular
> > design and needs wrt memory allocation.
> 
> You categorically stated that memory allocation off the main thread is 
> unsafe.

No, I didn't.  I said something else: that it wasn't safe to assume
memory allocations can be freely done in Emacs in non-main threads.

> Once you admit that this statement is incorrect

I don't have to admit anything, because I never said that.

> we can move on to the Emacs-specific discussion, since we cannot
> talk about Emacs specifics without understanding the platforms on
> which Emacs runs.

More to the point, we cannot talk about Emacs without a good
understanding of Emacs internals and coding practices.

> The distinction is important: Lisp allocation is unsafe because of the 
> layers we put on top of the system heap, not because the system heap is 
> itself unusable. For example, we can create a scheme where we have 
> multiple Lisp universes, each with its own heap and GC, and each bound 
> to a single thread. (Like Web Workers.) If system malloc were unsafe, 
> this scheme would not be thread-safe,  But since system malloc _is_ 
> thread safe, this Emacs-specific approach to multithreading becomes 
> feasible.

I never said it was infeasible.  I said that we are not yet ready for
that in Emacs.  Granted, given enough development and changes in our
practices, and enough experience with native malloc on most platforms,
some limited multithreading will be possible in Emacs.  Where exactly
to put those limits and how much development it will take remains to
be seen.

Once again, this is about the current situation and the current
infrastructure.  It is not about some future, nor about the
feasibility of this in general.  It was my impression that some of the
people in this thread thought they can start creating application
threads in Emacs tomorrow morning, so I wrote a few words of caution,
reminding them that there are currently several obstacles on that road
that need to be negotiated first.

> Emacs today can tolerate arbitrary memory allocations off the main 
> thread after dumping using the system heap. I know this to be case 
> because Emacs today, on the most common platforms --- OS X, GNU/Linux, 
> and Windows, all perform allocations off the main thread in very common 
> configurations _already_.

The only platform I know about that starts non-main threads which run
Emacs application code is MS-Windows, and there we don't allocate
anything off the heap, at least not off the same heap that is used by
the main (Lisp) thread.

What other threads on which platforms are you talking about?

> > As for "claims": this is more about gut feelings, based on the factors
> > I mentioned, than about anything else.  It is OK to disagree with gut
> > feelings, even if you agree with the facts.  It is NOT okay to make
> > this a discussion about my credibility.  If my credibility is being
> > questioned, I will simply step down.
> 
> When prototype aircraft were designed according to gut feelings about 
> how aerodynamics worked, they were unable to take off under their own 
> power. When the Wright brothers designed their aircraft using data from 
> a wind tunnel, their aircraft flew.

Irrelevant example.  This is about architecture and design, not about
implementation.  Intuition, creativity, and gut feelings are always
involved in this.