unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>, "Perry E. Metzger" <perry@piermont.com>
Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Can we go GTK-only?
Date: Tue, 1 Nov 2016 13:17:01 -0700	[thread overview]
Message-ID: <7875855e-b632-491c-c616-4f3662a525af@dancol.org> (raw)
In-Reply-To: <83ziljm0ei.fsf@gnu.org>

On 11/01/2016 01:05 PM, Eli Zaretskii wrote:
>> Date: Tue, 1 Nov 2016 15:20:27 -0400
>> From: "Perry E. Metzger" <perry@piermont.com>
>> Cc: Daniel Colascione <dancol@dancol.org>, raeburn@raeburn.org,
>>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>> On Tue, 01 Nov 2016 19:15:31 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>>>> Extraordinary claims require extraordinary evidence. Your claim
>>>> is extraordinary: it's been common practice for _decades_ to make
>>>> memory allocations from multiple threads in multithreaded
>>>> programming.
>>>
>>> This is simply incorrect.  On _some_ platforms, that is true.  But
>>> not on all, not anywhere near that.
>>
>> You've explicitly refused to name an exception, and no one else is
>> aware of one, so how can we give credence to your claim?
>>
>> Again, were your claim truly correct, no multithreaded C or C++
>> software would be stable on such a platform, so it seems like a very
>> unlikely statement. This is the sort of bug that would be found in the
>> first week that threading package shipped. The relevant standards have
>> also required it as long as threads have existed. I am disinclined to
>> believe it is true without evidence, and you refuse to present
>> evidence.
>
> I was not talking about multithreading in general.  I was talking
> specifically about Emacs, its coding practices, and its particular
> design and needs wrt memory allocation.

You categorically stated that memory allocation off the main thread is 
unsafe. Once you admit that this statement is incorrect, we can move on 
to the Emacs-specific discussion, since we cannot talk about Emacs 
specifics without understanding the platforms on which Emacs runs.

The distinction is important: Lisp allocation is unsafe because of the 
layers we put on top of the system heap, not because the system heap is 
itself unusable. For example, we can create a scheme where we have 
multiple Lisp universes, each with its own heap and GC, and each bound 
to a single thread. (Like Web Workers.) If system malloc were unsafe, 
this scheme would not be thread-safe,  But since system malloc _is_ 
thread safe, this Emacs-specific approach to multithreading becomes 
feasible.


> I named several factors that
> together lead me to the conclusion that we are not yet ready to allow
> arbitrary multithreading in Emacs, although we and the supported
> platforms are moving in the right direction.  The problems and issues
> with thread-safe malloc in C libraries is just one of these factors,
> perhaps not even the most important one, since at least in Emacs 25
> many platforms we support don't use their native malloc.  (We switched
> most of them to native malloc in Emacs 26, but we don't yet know
> whether the results will be good enough, although we hope so.)
>
> If you want to make this discussion a constructive one, please argue
> about these aspects: about Emacs and Emacs alone, and how it can or
> cannot tolerate arbitrary memory allocations, both for C and Lisp
> objects, in multiple threads.

Emacs today can tolerate arbitrary memory allocations off the main 
thread after dumping using the system heap. I know this to be case 
because Emacs today, on the most common platforms --- OS X, GNU/Linux, 
and Windows, all perform allocations off the main thread in very common 
configurations _already_.

> IOW, the arguments in such a
> constructive discussion should be about specific aspects of Emacs
> design and implementation, and about Emacs programming, that are
> related to memory management.
>
> As for "claims": this is more about gut feelings, based on the factors
> I mentioned, than about anything else.  It is OK to disagree with gut
> feelings, even if you agree with the facts.  It is NOT okay to make
> this a discussion about my credibility.  If my credibility is being
> questioned, I will simply step down.

When prototype aircraft were designed according to gut feelings about 
how aerodynamics worked, they were unable to take off under their own 
power. When the Wright brothers designed their aircraft using data from 
a wind tunnel, their aircraft flew.




  reply	other threads:[~2016-11-01 20:17 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
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 [this message]
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 20:33                                   ` Paul Eggert
2016-11-03  1:25                                   ` Richard Stallman
2016-11-02 19:25                                 ` Nikolaus Rath
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=7875855e-b632-491c-c616-4f3662a525af@dancol.org \
    --to=dancol@dancol.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=perry@piermont.com \
    --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).