From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Tue, 1 Nov 2016 13:22:02 -0400 Message-ID: <20161101132202.02a5e1eb@jabberwock.cb.piermont.com> 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> <20161101124112.2604a08c@jabberwock.cb.piermont.com> <83h97rnnsk.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1478021407 26267 195.159.176.226 (1 Nov 2016 17:30:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 17:30:07 +0000 (UTC) Cc: dancol@dancol.org, 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 18:30:03 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 1c1csU-0003S1-3Q for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 18:29:38 +0100 Original-Received: from localhost ([::1]:49573 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1csW-00017a-OZ for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 13:29:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1clC-00036G-9A for emacs-devel@gnu.org; Tue, 01 Nov 2016 13:22:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1clB-00078Z-Ef for emacs-devel@gnu.org; Tue, 01 Nov 2016 13:22:06 -0400 Original-Received: from hacklheber.piermont.com ([2001:470:30:84:e276:63ff:fe62:3400]:37516) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c1cl9-00077Y-Tb; Tue, 01 Nov 2016 13:22:03 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 2586B65A; Tue, 1 Nov 2016 13:22:03 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 04D4B2DE01E; Tue, 1 Nov 2016 13:22:03 -0400 (EDT) In-Reply-To: <83h97rnnsk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:470:30:84:e276:63ff:fe62:3400 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:209065 Archived-At: On Tue, 01 Nov 2016 18:54:35 +0200 Eli Zaretskii wrote: > > I was under the impression the requirement that malloc be thread > > safe was before now a POSIX/pthreads thing, not a C standard > > thing, and that this had been the case for a very long time. > > We don't only support POSIX platforms. It is also the case on Windows and on all non-POSIX platforms I'm aware of that are of significance. That said, I don't believe that Emacs supports much other than POSIX and Windows, so we could easily check the others. > And even for POSIX > platforms, you can find on the net reports about thread-unsafe > malloc up to 2013 and 2014. That's not "very long time". Are you sure this wasn't just a report from some people who linked with the wrong library? The standard has required that malloc be thread safe as long as pthreads has been around IIRC. I'm unaware of any such reports of lack of support, but if they exist, it would indicate a desperately broken platform that couldn't run any thread safe code to speak of. One of the first things one needs to do in order to support pthreads is to produce a libc that knows about pthread safety. If you don't have that, you can port essentially 0 thread safe programs and users can write essentially nothing. malloc is a very basic call. I could be wrong here, of course, but I'd need to see much more concrete evidence of it. > > I can look up old versions of the standard but I believe it was > > the case as long as pthreads has been around. > > My concern is not with the standards, but with the actual situation > out there. The actual implementations *have* to handle thread safety of the basic library calls or basically no software will run. malloc is such a basic call that if you didn't handle it correctly you couldn't expect pthreads to be of any use on your platform. Perry -- Perry E. Metzger perry@piermont.com