From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Tue, 1 Nov 2016 09:28:34 -0700 Organization: UCLA Computer Science Department Message-ID: <403a4fd8-f9da-82df-956b-a3187de83cf9@cs.ucla.edu> 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> 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 1478018829 23148 195.159.176.226 (1 Nov 2016 16:47:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 16:47:09 +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 , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 17:47:05 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 1c1cD4-0003s3-51 for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 17:46:50 +0100 Original-Received: from localhost ([::1]:49268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cD4-00076Q-Dy for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 12:46:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1bvZ-0000K7-FY for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:28:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1bvY-00069Z-Qz for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:28:45 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56274) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c1bvU-00068V-Pb; Tue, 01 Nov 2016 12:28:40 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0FE9D16075E; Tue, 1 Nov 2016 09:28:39 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GP7_s8M41Bm9; Tue, 1 Nov 2016 09:28:35 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3DFBB1607BC; Tue, 1 Nov 2016 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Y1W-uTwFbQNb; Tue, 1 Nov 2016 09:28:35 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 21F2716075E; Tue, 1 Nov 2016 09:28:35 -0700 (PDT) In-Reply-To: <83y413nsjm.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:209060 Archived-At: 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. > 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. > 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. > 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. xmalloc is like xsignal, Fcons, and lots of other functions that should be called only in the Emacs Lisp thread.