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 18:49:47 +0200 Message-ID: <83lgx3no0k.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> <403a4fd8-f9da-82df-956b-a3187de83cf9@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1478021368 9077 195.159.176.226 (1 Nov 2016 17:29:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 17:29:28 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org, raeburn@raeburn.org, monnier@iro.umontreal.ca To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 18:29:24 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 1c1crw-0007sK-Dx for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 18:29:04 +0100 Original-Received: from localhost ([::1]:49556 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1crz-0000eJ-1l for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 13:29:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cFj-00010i-HU for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:49:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1cFg-0004l5-Fe for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:49:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cFg-0004kv-CT; Tue, 01 Nov 2016 12:49:32 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4186 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c1cFf-0001FL-Hg; Tue, 01 Nov 2016 12:49:31 -0400 In-reply-to: <403a4fd8-f9da-82df-956b-a3187de83cf9@cs.ucla.edu> (message from Paul Eggert on Tue, 1 Nov 2016 09:28:34 -0700) 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:209064 Archived-At: > Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Paul Eggert > Date: Tue, 1 Nov 2016 09:28:34 -0700 > > On 11/01/2016 08:11 AM, Eli Zaretskii wrote: > > Only C11 mandates that malloc/realloc/free shall be thread-safe, and > we don't yet require C11. > > This is too pessimistic. C11 was the first C standard to talk about > threads, which is why it's the first C standard to specify whether > malloc is thread-safe. In practice it should be safe to assume that > malloc is thread-safe on multithreaded platforms, as C programmers would > have revolted en masse otherwise. "It should be safe" and "it's safe" are 2 different things. > > 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. > > ralloc is not thread-safe at all. > > Yes, and ralloc as it stands should not be used on modern platforms. We > clearly need to move in that direction anyway. We do move in that direction, but we aren't there yet. > > 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. Like I said: we are barely out of the woods, so allocations from the heap in non-main threads should be avoided.