Re: Can we go GTK-only?

[Daniel Colascione <dancol@dancol.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ken Raeburn <raeburn@raeburn.org>
>> Date: Mon, 31 Oct 2016 14:22:50 -0400
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>>  emacs-devel@gnu.org
>> 
>> 
>> On Oct 31, 2016, at 11:54, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> >   One problem with
>> > having too much code in separate threads is that only the main thread
>> > can call malloc/free, i.e. you cannot create/destroy objects in other
>> > threads.
>> 
>> Wow.  Is that a Windows limitation?  It’s certainly not true under POSIX threads.
>
> No, it's a general limitation: malloc is non-reentrant.

Reentrancy is not the same as thread safety.

Of course you can call malloc from multiple threads. Otherwise, projects
like jemalloc would be pointless. You can freely allocate and deallocate
from different threads on both POSIX and Windows systems, and there is
no need to free an object on the thread that allocated it.

>> Creating Lisp objects, that’d be another matter, unless locking is introduced to the allocator.
>
> If you cannot allocate Lisp objects, the scope of what you can do in
> the non-main threads is greatly diminished.  E.g., no computation
> intensive jobs that operate on buffer text can be off-loaded to other
> threads.

Allocation of lisp objects is different. _That_ isn't thread safe
right now. The easiest way to address this problem is a GIL.