[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:06:14 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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

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

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.

reply via email to

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