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: Eli Zaretskii
Subject: Re: Can we go GTK-only?
Date: Tue, 01 Nov 2016 19:08:51 +0200

> Cc: address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Tue, 1 Nov 2016 09:54:51 -0700
> 
> >>  > 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.

You can find them yourself if you are interested.  I have more
important things to do with my time.

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

We'd have to write that stuff before this issue can be regarded as
solved.

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

That's what I'm saying: that class of programs is not yet feasible for
Emacs.  In a couple of years, maybe.

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

We are not talking about your Emacs or mine.  (In my Emacs, those
problems cannot happen at all, because as you know on Windows each DLL
calls the memory allocator it was linked against, so the tricks Emacs
plays with its private malloc are harmless, because no external
library will ever call it.)

But I was talking about the mainstream Emacs on J.R.Hacker's random
machine out there.  That is the platform about whose stability I
worry.



reply via email to

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