[Top][All Lists]

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

Re: Can we go GTK-only?

From: Daniel Colascione
Subject: Re: Can we go GTK-only?
Date: Tue, 1 Nov 2016 10:18:58 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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

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

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.

reply via email to

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