emacs-devel
[Top][All Lists]
Advanced

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

On 11/01/2016 09:49 AM, Eli Zaretskii wrote:
Cc: address@hidden, address@hidden, address@hidden
From: Paul Eggert <address@hidden>
Date: Tue, 1 Nov 2016 09:28:34 -0700

On 11/01/2016 08:11 AM, Eli Zaretskii wrote:
 > Only C11 mandates that malloc/realloc/free shall be thread-safe, and
we don't yet require C11.

This is too pessimistic. C11 was the first C standard to talk about
threads, which is why it's the first C standard to specify whether
malloc is thread-safe. In practice it should be safe to assume that
malloc is thread-safe on multithreaded platforms, as C programmers would
have revolted en masse otherwise.

"It should be safe" and "it's safe" are 2 different things.

 > gmalloc is only thread-safe if Emacs is built with pthreads.

Yes, and that's what one would expect. If you build Emacs in
single-threaded mode, malloc won't be thread-safe. But in the normal
case nowadays, malloc should be thread-safe.

pthreads is not the only way to have threads.

On any modern system POSIX system it is. Counterexample, please.

 > ralloc is not thread-safe at all.

Yes, and ralloc as it stands should not be used on modern platforms. We
clearly need to move in that direction anyway.

We do move in that direction, but we aren't there yet.

 > xmalloc calls memory_full, which manipulates global state and calls
xsignal, so that is not thread-safe, either.

That's fine, so long as xmalloc is called only in the Emacs Lisp thread.

I'd imagine any code that wants to allocate from the heap will call
xmalloc, as we never call malloc directly in Emacs AFAIK.

That's because we want xmalloc to handle memory exhaustion in a sane way. A thread calling system malloc on its own can handle memory exhaustion a different way. Memory exhaustion being reported in some way is what really matters.

Like I said: we are barely out of the woods, so allocations from the
heap in non-main threads should be avoided.

This restriction makes a big class of programs very difficult to write. Besides, in my Emacs right now, I have in addition to the main thread a generic glib worker thread, a dconf worker thread, and a gdbus thread. I'd be amazed if none of these threads allocated memory.



reply via email to

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