unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org, raeburn@raeburn.org,
	monnier@iro.umontreal.ca
Subject: Re: Can we go GTK-only?
Date: Tue, 01 Nov 2016 19:08:51 +0200	[thread overview]
Message-ID: <83eg2vnn4s.fsf@gnu.org> (raw)
In-Reply-To: <633d43c4-946e-e318-d8de-be1c2fde26f7@dancol.org> (message from Daniel Colascione on Tue, 1 Nov 2016 09:54:51 -0700)

> Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> 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	other threads:[~2016-11-01 17:08 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-27 19:54 Can we go GTK-only? Daniel Colascione
2016-10-27 20:05 ` Frank Haun
2016-10-27 20:45   ` Daniel Colascione
2016-10-27 21:08     ` Frank Haun
2016-10-27 20:32 ` Paul Eggert
2016-10-27 23:15   ` Perry E. Metzger
2016-10-28  7:13     ` Eli Zaretskii
2016-10-28  2:35 ` Richard Stallman
2016-10-28  6:22 ` Eli Zaretskii
2016-10-28  7:27   ` Ulrich Mueller
2016-10-28  8:15     ` Eli Zaretskii
2016-10-28 10:48   ` Frank Haun
2016-10-28 12:26     ` Eli Zaretskii
2016-10-28 13:35 ` Stefan Monnier
2016-10-30 14:43   ` Ken Raeburn
2016-10-30 21:42     ` Stefan Monnier
2016-10-30 22:49       ` Daniel Colascione
2016-10-30 23:57         ` Stefan Monnier
2016-10-31  3:37           ` Eli Zaretskii
2016-10-31 15:57           ` Eli Zaretskii
2016-10-31  0:00         ` YAMAMOTO Mitsuharu
2016-10-31  8:24           ` Ken Raeburn
2016-10-31 16:34             ` Perry E. Metzger
2016-11-01  8:22             ` YAMAMOTO Mitsuharu
2016-10-31  3:33         ` Eli Zaretskii
2016-10-31 15:57           ` Perry E. Metzger
2016-10-31 15:56         ` Eli Zaretskii
2016-10-31 15:59           ` Daniel Colascione
2016-10-31 16:47             ` Eli Zaretskii
2016-10-31 17:54               ` Perry E. Metzger
2016-10-31 20:50                 ` Eli Zaretskii
2016-10-31 15:52       ` Eli Zaretskii
2016-10-31 15:54     ` Eli Zaretskii
2016-10-31 18:22       ` Ken Raeburn
2016-10-31 20:53         ` Eli Zaretskii
2016-10-31 21:04           ` Daniel Colascione
2016-11-01 15:11             ` Eli Zaretskii
2016-11-01 16:28               ` Paul Eggert
2016-11-01 16:49                 ` Eli Zaretskii
2016-11-01 16:54                   ` Daniel Colascione
2016-11-01 17:08                     ` Eli Zaretskii [this message]
2016-11-01 17:16                       ` Daniel Colascione
2016-11-01 19:15                       ` Perry E. Metzger
2016-11-01 19:28                         ` Lars Ingebrigtsen
2016-11-01 19:31                         ` Eli Zaretskii
2016-11-01 16:55                   ` Paul Eggert
2016-11-01 17:15                 ` Perry E. Metzger
2016-11-01 16:41               ` Perry E. Metzger
2016-11-01 16:54                 ` Eli Zaretskii
2016-11-01 17:22                   ` Perry E. Metzger
2016-11-01 17:46                     ` Eli Zaretskii
2016-11-01 17:56                       ` Perry E. Metzger
2016-11-01 19:35                       ` Perry E. Metzger
2016-11-01 16:45               ` Daniel Colascione
2016-11-01 17:01                 ` Eli Zaretskii
2016-11-01 17:06                   ` Daniel Colascione
2016-11-01 17:15                     ` Eli Zaretskii
2016-11-01 17:18                       ` Daniel Colascione
2016-11-01 17:44                         ` Eli Zaretskii
2016-11-01 17:45                           ` Daniel Colascione
2016-11-01 19:14                       ` Stefan Monnier
2016-11-01 19:22                         ` Eli Zaretskii
2016-11-01 19:42                           ` Perry E. Metzger
2016-11-01 19:20                       ` Perry E. Metzger
2016-11-01 20:05                         ` Eli Zaretskii
2016-11-01 20:17                           ` Daniel Colascione
2016-11-01 20:42                             ` Eli Zaretskii
2016-11-02  2:26                               ` Perry E. Metzger
2016-11-02 15:49                                 ` Eli Zaretskii
2016-11-02 15:55                                   ` Daniel Colascione
2016-11-02  5:00                               ` YAMAMOTO Mitsuharu
2016-11-02 15:46                                 ` Eli Zaretskii
2016-11-03  3:43                                   ` YAMAMOTO Mitsuharu
2016-11-03 17:40                                     ` Eli Zaretskii
2016-11-02  0:27                           ` Stefan Monnier
2016-11-02 15:53                             ` Eli Zaretskii
2016-11-02 16:04                               ` Stefan Monnier
2016-11-02 19:25                                 ` Nikolaus Rath
2016-11-02 19:25                                 ` Nikolaus Rath
2016-11-02 20:33                                   ` Paul Eggert
2016-11-03  1:25                                   ` Richard Stallman
2016-11-02 20:13                                 ` Eli Zaretskii
2016-11-03  3:29                                   ` Perry E. Metzger
2016-11-03 18:07                           ` John Wiegley
2016-11-03 22:07                             ` John Wiegley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83eg2vnn4s.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dancol@dancol.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=raeburn@raeburn.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).