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 10:06:14 -0700
> 
> On 11/01/2016 10:01 AM, Eli Zaretskii wrote:
> >> Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >> From: Daniel Colascione <dancol@dancol.org>
> >> Date: Tue, 1 Nov 2016 09:45:41 -0700
> >>
> >> Name one system we support that both _has_ threads and that doesn't have
> >> a thread-safe system malloc. If we're using our own malloc and _that_
> >> isn't thread-safe, that doesn't count. I insist that on modern systems,
> >> the malloc and free that come with libc are thread safe.
> >
> > You can insist all you like, it won't change my mind: thread-safety in
> > malloc is only now becoming widespread and reliable enough, and older
> > systems where there are various bugs in that regard are still with us
> > in significant numbers.  Just google the keywords, and you will see
> > the bug reports and their dates.
> 
> 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.

> > I think we've lost context: this thread is not about the concurrency
> > branch, where only one thread runs at a time, for which that Python
> > paper is irrelevant.  This thread (or at least what I wrote above) is
> > about the proposal to have more than one thread that performs
> > CPU-intensive tasks, so that the main thread could go about its
> > business.  For that, you will definitely want CPU preemption, because
> > those tasks don't have to run Lisp.
> 
> If those CPU-intensive tasks are not written in Lisp, there is no need 
> to hold the GIL while running them, so other threads can run Lisp in 
> parallel.

CPU-intensive threads that cannot manipulate Lisp objects (not run
Lisp, but create and destroy Lisp objects) are not very useful in
Emacs.