Re: Can we go GTK-only?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 1 Nov 2016 15:20:27 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Daniel Colascione <dancol@dancol.org>, raeburn@raeburn.org,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On Tue, 01 Nov 2016 19:15:31 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > > Extraordinary claims require extraordinary evidence. Your claim
> > > is extraordinary: it's been common practice for _decades_ to make
> > > memory allocations from multiple threads in multithreaded
> > > programming.
> > 
> > This is simply incorrect.  On _some_ platforms, that is true.  But
> > not on all, not anywhere near that.
> 
> You've explicitly refused to name an exception, and no one else is
> aware of one, so how can we give credence to your claim?
> 
> Again, were your claim truly correct, no multithreaded C or C++
> software would be stable on such a platform, so it seems like a very
> unlikely statement. This is the sort of bug that would be found in the
> first week that threading package shipped. The relevant standards have
> also required it as long as threads have existed. I am disinclined to
> believe it is true without evidence, and you refuse to present
> evidence.

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.  I named several factors that
together lead me to the conclusion that we are not yet ready to allow
arbitrary multithreading in Emacs, although we and the supported
platforms are moving in the right direction.  The problems and issues
with thread-safe malloc in C libraries is just one of these factors,
perhaps not even the most important one, since at least in Emacs 25
many platforms we support don't use their native malloc.  (We switched
most of them to native malloc in Emacs 26, but we don't yet know
whether the results will be good enough, although we hope so.)

If you want to make this discussion a constructive one, please argue
about these aspects: about Emacs and Emacs alone, and how it can or
cannot tolerate arbitrary memory allocations, both for C and Lisp
objects, in multiple threads.  IOW, the arguments in such a
constructive discussion should be about specific aspects of Emacs
design and implementation, and about Emacs programming, that are
related to memory management.

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.

> By the way: no one reasonable will think less of you if you later say
> you made a mistake. People make mistakes.

This goes both ways, of course.