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:45:41 -0700 Message-ID: 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: 8bit X-Trace: blaine.gmane.org 1478022036 8192 195.159.176.226 (1 Nov 2016 17:40:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 17:40:36 +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 Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 18:40:31 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 1c1d2p-0008Pn-Mv for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 18:40:19 +0100 Original-Received: from localhost ([::1]:49701 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1d2s-0001PL-Cb for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 13:40:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1cCD-0006XQ-HE for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:45:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1cCA-0003OC-FS for emacs-devel@gnu.org; Tue, 01 Nov 2016 12:45:57 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33832) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1cC9-0003MD-Pa; Tue, 01 Nov 2016 12:45:54 -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=S2cuN+cT3zCg+K1wUx5XzNVrcWGpv3FqMg71tUZMQ5w=; b=LTVBIjSMrDg7hEgsXscWGpzFRpaFxqc15UIr1xXuo5tvxB0geXqXpMN/eN7PdQvhPoSWvgkbAalXjDq+S+xrB5LHUBPgdvfRoIH0GF+xJICUVSFNJtlXJ+dnZoY4SANJ+Z5OkvmGKc+UXk8eAkc9see8MMSxjkdzrehsLJZpxiXfneL5R8G3MkTFvNqX8M5GmW5KIc/oZ1FoK7mZm3IQ2bKdeWaUiTXhSLaxn8vXMpXBTI+bcEVskqIz1Rw6uC5otF/1krBKFd0RYYcph/c0huhJ8UJgqFjEwt4Dh6FpHcjvyPcPBquqtL8pxvjl3ZAu55WONZcy0XswoqVBe3m2Xw==; 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 1c1cC1-0004Ap-5T; Tue, 01 Nov 2016 09:45:45 -0700 In-Reply-To: <83y413nsjm.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:209071 Archived-At: On 11/01/2016 08:11 AM, Eli Zaretskii wrote: >> From: Daniel Colascione >> Date: Mon, 31 Oct 2016 14:04:54 -0700 >> Cc: Ken Raeburn , monnier@iro.umontreal.ca, >> emacs-devel@gnu.org >> >>>>> One problem with >>>>> having too much code in separate threads is that only the main thread >>>>> can call malloc/free, i.e. you cannot create/destroy objects in other >>>>> threads. >>>> >> [...] >> Of course you can call malloc from multiple threads. Otherwise, projects >> like jemalloc would be pointless. You can freely allocate and deallocate >> from different threads on both POSIX and Windows systems, and there is >> no need to free an object on the thread that allocated it. > > IMO, this is not a safe assumption, even though in practice more and > more systems out there provide thread-safe native malloc. Only C11 > mandates that malloc/realloc/free shall be thread-safe, and we don't > yet require C11. The C99 standard is silent on threads, so of course it doesn't mandate thread-safe malloc and free. gmalloc is only thread-safe if Emacs is built with > pthreads. ralloc is not thread-safe at all. xmalloc calls > memory_full, which manipulates global state and calls xsignal, so that > is not thread-safe, either. 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. > IOW, we are barely out of the woods with thread-safety of memory > allocation, No we're not. When it comes to the thread safety of memory allocation, we're well out of the woods, down the mountains, across the plains, in the city, and siting at a coffee shop sipping a our-over latte while reading an article on our fancy e-readers about how nobody goes outside anymore. That's how well-established thread-safe malloc and free are on systems that support threads at all. > so IMO it's too early for us to build basic infrastructure > on the thread-safety assumption. For experimental and exotic > features, yes, but not for something that must work well on all > supported systems. No it isn't. >>>> Creating Lisp objects, that’d be another matter, unless locking is >>>> introduced to the allocator. >>> >>> If you cannot allocate Lisp objects, the scope of what you can do in >>> the non-main threads is greatly diminished. E.g., no computation >>> intensive jobs that operate on buffer text can be off-loaded to other >>> threads. >> >> 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. A GIL would let multiple threads run Lisp code and, while blocked, call into native code that did computation-intensive work. The main effect of the GIL is to prevent Lisp taking advantage of hardware parallelism, but since we're already in the position of being unable to take advantage of hardware parallelism, I don't see it really hurting us. And at least we get concurrency and the potential to release the GIL while we do other work (like redisplay).