Re: Can we go GTK-only?

[Daniel Colascione]

On 11/01/2016 08:11 AM, Eli Zaretskii wrote:
> > 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.

The C99 standard is silent on threads, so of course it doesn't mandate 
thread-safe malloc and free.

  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.

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.

> IOW, we are barely out of the woods with thread-safety of memory
> allocation,

No we're not. When it comes to the thread safety of memory allocation, 
we're well out of the woods, down the mountains, across the plains, in 
the city, and siting at a coffee shop sipping a our-over latte while 
reading an article on our fancy e-readers about how nobody goes outside 
anymore. That's how well-established thread-safe malloc and free are on 
systems that support threads at all.

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

No it isn't.

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

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. A GIL would let multiple threads run Lisp code and, while 
blocked, call into native code that did computation-intensive work. The 
main effect of the GIL is to prevent Lisp taking advantage of hardware 
parallelism, but since we're already in the position of being unable to 
take advantage of hardware parallelism, I don't see it really hurting us.

And at least we get concurrency and the potential to release the GIL 
while we do other work (like redisplay).