Re: Can we go GTK-only?

[Eli Zaretskii]

> From: Daniel Colascione <address@hidden>
> Date: Mon, 31 Oct 2016 14:04:54 -0700
> Cc: Ken Raeburn <address@hidden>, address@hidden,
>       address@hidden
> 
> >> >   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.
> >> 
> [...]
> 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.

IMO, this is not a safe assumption, even though in practice more and
more systems out there provide thread-safe native malloc.  Only C11
mandates that malloc/realloc/free shall be thread-safe, and we don't
yet require C11.  gmalloc is only thread-safe if Emacs is built with
pthreads.  ralloc is not thread-safe at all.  xmalloc calls
memory_full, which manipulates global state and calls xsignal, so that
is not thread-safe, either.

IOW, we are barely out of the woods with thread-safety of memory
allocation, so IMO it's too early for us to build basic infrastructure
on the thread-safety assumption.  For experimental and exotic
features, yes, but not for something that must work well on all
supported systems.

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

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.