From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "John Wiegley" Newsgroups: gmane.emacs.devel Subject: Re: Make computational threads leave user interface usable Date: Wed, 01 Nov 2017 11:12:02 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1509559949 6647 195.159.176.226 (1 Nov 2017 18:12:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Nov 2017 18:12:29 +0000 (UTC) User-Agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/26.0 (darwin) Cc: Emacs developers To: Paul Pogonyshev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 01 19:12:23 2017 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 1e9xUx-0000pX-7V for ged-emacs-devel@m.gmane.org; Wed, 01 Nov 2017 19:12:19 +0100 Original-Received: from localhost ([::1]:57187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9xV4-0002Hh-8z for ged-emacs-devel@m.gmane.org; Wed, 01 Nov 2017 14:12:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9xUs-0002ER-Ey for emacs-devel@gnu.org; Wed, 01 Nov 2017 14:12:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9xUr-0002Ri-A6 for emacs-devel@gnu.org; Wed, 01 Nov 2017 14:12:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9xUl-0002Ot-J0; Wed, 01 Nov 2017 14:12:07 -0400 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:43727) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1e9xUl-0002a7-9K; Wed, 01 Nov 2017 14:12:07 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id A3E8F2116B; Wed, 1 Nov 2017 14:12:06 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 01 Nov 2017 14:12:06 -0400 X-ME-Sender: Original-Received: from Vulcan.local (76-234-69-149.lightspeed.frokca.sbcglobal.net [76.234.69.149]) by mail.messagingengine.com (Postfix) with ESMTPA id 697817F8F6; Wed, 1 Nov 2017 14:12:06 -0400 (EDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id 71578A693BAC; Wed, 1 Nov 2017 11:12:05 -0700 (PDT) In-Reply-To: (Paul Pogonyshev's message of "Wed, 1 Nov 2017 16:06:23 +0100") Mail-Followup-To: Paul Pogonyshev , Emacs developers 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:219850 Archived-At: >>>>> "PP" == Paul Pogonyshev writes: PP> Since several versions Emacs has Lisp threads, but they are not used much, PP> because 1) only one thread executes at any given time; 2) threads yield PP> control to each other only with explicit (thread-yield) call or IO blocks. PP> Which means that it is pointless to start a new thread for heavy PP> computation: it will lock UI until finished anyway. I wouldn't say it's pointless, just that it calls for a programming regimen where you add (thread-yield) calls at appropriate places. PP> Attached patch tries to solve point 2 only by making threads PP> automatically yield control to each other from time to time. The patch PP> is mainly for discussion. This would introduce the sort of indeterminacy that raised so much objection to threading support last year. I'm fairly opposed to pre-emptive threading until we've heard from the field about the success of green threading. (make-thread (lambda () (dotimes (n 10000000) (when (= (% n 1000000) 0) (message "%s" n))) (message "done"))) I think the problem here is not with Emacs' threading model, but how you've written the code. It is currently a _feature_ that control is not taken away while engaged in such a computation. For example, this allows delicate state manipulation without interference from other threads. If periodic suspension were desired, you could have written: (make-thread (lambda () (dotimes (n 10000000) (thread-yield) (when (= (% n 1000000) 0) (message "%s" n))) (message "done"))) This gives the UI access to Emacs again, but otherwise keeps executing if no other threads need control. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2