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 10:16:07 -0700 Message-ID: <2c52221b-e0fc-3a7b-ea71-a1c001cfc6bc@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> <633d43c4-946e-e318-d8de-be1c2fde26f7@dancol.org> <83eg2vnn4s.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 1478023828 30454 195.159.176.226 (1 Nov 2016 18:10:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 18:10:28 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org, raeburn@raeburn.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 19:10: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 1c1dVY-0004nG-94 for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 19:10:00 +0100 Original-Received: from localhost ([::1]:50082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1dVa-0007q3-Us for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 14:10:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cfX-0006jl-MW for emacs-devel@gnu.org; Tue, 01 Nov 2016 13:16:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1cfU-00054z-GO for emacs-devel@gnu.org; Tue, 01 Nov 2016 13:16:15 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:34212) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1cfU-00053g-6M; Tue, 01 Nov 2016 13:16:12 -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=GypeqnAPOH5FtkEdMOS+Shmmb//x5wqaC5kcmkbypAs=; b=RHNRZokNsFo8lZ8munufpzEeL1NwgAcH7PWU4OZjnvm9KxB034KoroEtX1sPiRUyRmxuXXBh4hH5k2RKe84vkGWSxW8aYT/TjKKVbCaG0gdQnCXla+OqTmKJGFJil0PXKo1XS2FI4M4Ig1a34Y1DzF3NU183jIBFnhFqeat0U0oRNOd15G4Sont9GfKw/XNAlFG+9rexYMc8qXvNjeeM8WbW/Hcg3I7GQC0Km1l3BqGetvbPBgzo7lrXUyrm9BkAjwomOaKazzbQRXyMK+NNpw4gR83INe2HW6ZY4xFDbHYxvFRtgIphg5ZyQFa1hZU4geouC7k9YwMAaSWkzOvFEA==; 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 1c1cfT-0004OI-6m; Tue, 01 Nov 2016 10:16:11 -0700 In-Reply-To: <83eg2vnn4s.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:209079 Archived-At: On 11/01/2016 10:08 AM, Eli Zaretskii wrote: >> Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Tue, 1 Nov 2016 09:54:51 -0700 >> >>>> > 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. > > You can find them yourself if you are interested. I have more > important things to do with my time. What other thread mechanism? Windows threads? Malloc is thread-safe. GNU Pth? Not really multi-threaded, so malloc is safe. Old-fashioned pre-pthreads Sun threads? We don't support that platform, and I strongly suspect malloc was safe there too. You're the one making the unusual claim, so you're the one who needs to provide evidence. >>>> > 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. > > We'd have to write that stuff before this issue can be regarded as > solved. It'll be solved in whatever code does the memory allocation. Nobody knows yet what that looks like, because it isn't been written, but it's obvious in broad strokes that you can check whether malloc returns NULL and stop what you're doing or set an error flag _somehow_. There's no technical problem to be solved: just code to be written. > >>> 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. > > That's what I'm saying: that class of programs is not yet feasible for > Emacs. In a couple of years, maybe. What will have changed in a few years? If you have evidence that we have a problem now, please provide it. If your presupposition of evidence-free now, it'll be evidence-free in a few years too. >> 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. > > We are not talking about your Emacs or mine. (In my Emacs, those > problems cannot happen at all, because as you know on Windows each DLL > calls the memory allocator it was linked against, so the tricks Emacs > plays with its private malloc are harmless, because no external > library will ever call it.) > > But I was talking about the mainstream Emacs on J.R.Hacker's random > machine out there. That is the platform about whose stability I > worry. "R.Hacker's random machine" is not a supported platform. Name a supported platform that concerns you.