Re: Can we go GTK-only?

[Daniel Colascione <dancol@dancol.org>]

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. Programs 
that do this, many of which I use every day, run reliably. You need to 
provide evidence that what you say is true.

I did conduct search you suggested. The examples I found all involves 
people not compiling with the compile flags for enabling thread safety. 
What did these people expect to happen?

>>>> Allocation of lisp objects is different. _That_ isn't thread safe
>>>> right now. The easiest way to address this problem is a GIL.
>>>
>>> GIL hurts performance so much that I'd question any GIL-based design
>>> that attempts to support off-loading CPU-intensive tasks to worker
>>> threads.
>>
>> On what basis do you make this claim? As someone mentioned previously,
>> that Python paper isn't really relevant, as we're not doing CPU
>> preemption.
>
> 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.