Re: Can we go GTK-only?

[Daniel Colascione]

On 11/01/2016 10:15 AM, Eli Zaretskii wrote:
> > Cc: address@hidden, address@hidden, address@hidden
> > From: Daniel Colascione <address@hidden>
> > Date: Tue, 1 Nov 2016 10:06:14 -0700
> >
> > On 11/01/2016 10:01 AM, Eli Zaretskii wrote:
> > > > Cc: address@hidden, address@hidden, address@hidden
> > > > From: Daniel Colascione <address@hidden>
> > > > 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'm not asking you to enumerate all platforms with both threads and 
thread-unsafe malloc. I'm just asking for _one_ platform that a) has 
threads, b) has thread-unsafe malloc, and that c) Emacs supports today. 
If you're researched this topic, you should be able to name one.

> > > 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.

Redisplay itself can run without invoking Lisp _most_ of the time, and 
it can take the GIL when it does. Other tasks, like image decoding and 
calls into native modules, can also run without invoking Lisp.