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 09:54:51 -0700 Message-ID: <633d43c4-946e-e318-d8de-be1c2fde26f7@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> <403a4fd8-f9da-82df-956b-a3187de83cf9@cs.ucla.edu> <83lgx3no0k.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 1478021173 20779 195.159.176.226 (1 Nov 2016 17:26:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 17:26:13 +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 , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 18:26:09 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 1c1coh-0001le-8r for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 18:25:43 +0100 Original-Received: from localhost ([::1]:49530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cok-0005BC-0X for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 13:25:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cKx-0005WO-Rk for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:55:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1cKu-0006OO-5E for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:54:59 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33840) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1cKt-0006OG-Rp; Tue, 01 Nov 2016 12:54:56 -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=noOCMS1d0VzIzRC5Kfe+HIa0ekxMLN/Ay1XQMXHD21g=; b=lulFQkkBVBfiSInw4fGAPEouMBOF3rOAUY4ppSpwCTupC9p+G0S6Fmjh+vYbkfM+1tuPM+o3aYsHzjungaBkQ7swqpC1vhjtJrapdwFbJLM+94i7Vbnv+q0bbg3fJgowIRQ02x1K5ApBcXLu7xoVpCcq6dNEqZplq/VsdXV3Icn+7XHxE0XrMdFQClpW6MgMRTglWGdKev3sSEtGpRzJFHbJ5QEnWuxrXKf63nLEOCfaSZ4ZIc1wf+EqwnW9WsU/Eun5l8xS3q3X+hxfHyoOKPMfhQaBWL8cvD/waGs7KuwIswMyzE1DU8A8CJSALk6duwiWRRHMBbab2KrDUJJd9g==; 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 1c1cKs-0004Dd-OR; Tue, 01 Nov 2016 09:54:54 -0700 In-Reply-To: <83lgx3no0k.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:209063 Archived-At: On 11/01/2016 09:49 AM, Eli Zaretskii wrote: >> 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. On any modern system POSIX system it is. Counterexample, please. >> > 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. That's because we want xmalloc to handle memory exhaustion in a sane way. A thread calling system malloc on its own can handle memory exhaustion a different way. Memory exhaustion being reported in some way is what really matters. > Like I said: we are barely out of the woods, so allocations from the > heap in non-main threads should be avoided. This restriction makes a big class of programs very difficult to write. Besides, in my Emacs right now, I have in addition to the main thread a generic glib worker thread, a dconf worker thread, and a gdbus thread. I'd be amazed if none of these threads allocated memory.