From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Tue, 1 Nov 2016 13:17:01 -0700 Message-ID: <7875855e-b632-491c-c616-4f3662a525af@dancol.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> <83ziljm0ei.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1478031484 11175 195.159.176.226 (1 Nov 2016 20:18:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 20:18:04 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 21:17:59 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 1c1fVF-0001Ks-HX for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 21:17:50 +0100 Original-Received: from localhost ([::1]:51078 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fVI-0006sl-AY for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 16:17:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1fUe-0006sQ-8u for emacs-devel@gnu.org; Tue, 01 Nov 2016 16:17:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1fUa-0007Kg-FD for emacs-devel@gnu.org; Tue, 01 Nov 2016 16:17:12 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36410) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1fUa-0007Ka-5b; Tue, 01 Nov 2016 16:17:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=6gOxf/vcBV62oN3bMXXnTjCUjZ+znR4TKzmAFxxYeto=; b=XMR369nkS+SquONDc6qZj03ZsJLg1wIKQkG1tohwZQ2lSTLyjEScVDC0WUFuD64aQ2gUUTlD+a6XolGSHot7QBYxje3pg2vtbjwmYCkln8kjh1Ds/gdXDQAiNaJiroWvsg1Lskj+eW1a3WylAzuTIDTv87/4sbmw2hPi0hi7jtFuektXVFUKMZQjk0hHRCZVkqooYY2WDt4vXQkPAZCOn1S+S6Q1ulTNJpH+Cd/VnXnYY6B6qN+5xkCgpPw8EntgCg0SHn5d0PlzIfb0cMJ1uDPJwTzsN+0QPxqkgzzuauPPpi57XXHD/CwvMntGfqn9cVa3tk2dfGmFzq+jnYleVg==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1c1fUX-0005fw-6k; Tue, 01 Nov 2016 13:17:05 -0700 In-Reply-To: <83ziljm0ei.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209092 Archived-At: On 11/01/2016 01:05 PM, Eli Zaretskii wrote: >> 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. 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.