From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Tue, 01 Nov 2016 22:05:09 +0200 Message-ID: <83ziljm0ei.fsf@gnu.org> References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> <83bmy0pl8p.fsf@gnu.org> <831sywp7ew.fsf@gnu.org> <83y413nsjm.fsf@gnu.org> <83funbnngl.fsf@gnu.org> <83d1ifnmto.fsf@gnu.org> <20161101152027.5e94b6cc@jabberwock.cb.piermont.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1478030926 25063 195.159.176.226 (1 Nov 2016 20:08:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 20:08:46 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org, raeburn@raeburn.org, monnier@iro.umontreal.ca To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 21:08:38 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1fLv-0002n1-QV for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 21:08:11 +0100 Original-Received: from localhost ([::1]:50987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fLy-0004Tx-JK for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 16:08:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fJ7-0002jE-I8 for emacs-devel@gnu.org; Tue, 01 Nov 2016 16:05:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1fJ3-0001oE-PH for emacs-devel@gnu.org; Tue, 01 Nov 2016 16:05:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fJ3-0001o9-Lz; Tue, 01 Nov 2016 16:05:13 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4368 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c1fJ0-0003re-Pt; Tue, 01 Nov 2016 16:05:13 -0400 In-reply-to: <20161101152027.5e94b6cc@jabberwock.cb.piermont.com> (perry@piermont.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209091 Archived-At: > Date: Tue, 1 Nov 2016 15:20:27 -0400 > From: "Perry E. Metzger" > Cc: Daniel Colascione , raeburn@raeburn.org, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > > On Tue, 01 Nov 2016 19:15:31 +0200 Eli Zaretskii 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. 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. 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. > By the way: no one reasonable will think less of you if you later say > you made a mistake. People make mistakes. This goes both ways, of course.