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 19:01:46 +0200 Message-ID: <83funbnngl.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1478022870 8759 195.159.176.226 (1 Nov 2016 17:54:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 17:54:30 +0000 (UTC) Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 18:54: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 1c1dGB-0000HG-8L for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 18:54:07 +0100 Original-Received: from localhost ([::1]:49879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1dGD-0003im-S6 for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 13:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cRL-0002qG-FO for emacs-devel@gnu.org; Tue, 01 Nov 2016 13:01:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1cRH-0000Jy-LE for emacs-devel@gnu.org; Tue, 01 Nov 2016 13:01:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cRH-0000Ju-Hw; Tue, 01 Nov 2016 13:01:31 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4191 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c1cRG-0001Yd-NQ; Tue, 01 Nov 2016 13:01:31 -0400 In-reply-to: (message from Daniel Colascione on Tue, 1 Nov 2016 09:45:41 -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:209075 Archived-At: > Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Daniel Colascione > Date: Tue, 1 Nov 2016 09:45:41 -0700 > > Name one system we support that both _has_ threads and that doesn't have > a thread-safe system malloc. If we're using our own malloc and _that_ > isn't thread-safe, that doesn't count. I insist that on modern systems, > the malloc and free that come with libc are thread safe. You can insist all you like, it won't change my mind: thread-safety in malloc is only now becoming widespread and reliable enough, and older systems where there are various bugs in that regard are still with us in significant numbers. Just google the keywords, and you will see the bug reports and their dates. > >> Allocation of lisp objects is different. _That_ isn't thread safe > >> right now. The easiest way to address this problem is a GIL. > > > > GIL hurts performance so much that I'd question any GIL-based design > > that attempts to support off-loading CPU-intensive tasks to worker > > threads. > > On what basis do you make this claim? As someone mentioned previously, > that Python paper isn't really relevant, as we're not doing CPU > preemption. I think we've lost context: this thread is not about the concurrency branch, where only one thread runs at a time, for which that Python paper is irrelevant. This thread (or at least what I wrote above) is about the proposal to have more than one thread that performs CPU-intensive tasks, so that the main thread could go about its business. For that, you will definitely want CPU preemption, because those tasks don't have to run Lisp.