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: Make computational threads leave user interface usable Date: Wed, 01 Nov 2017 22:03:54 +0200 Message-ID: <831slhsr4l.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1509566686 13084 195.159.176.226 (1 Nov 2017 20:04:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Nov 2017 20:04:46 +0000 (UTC) Cc: pogonyshev@gmail.com, emacs-devel@gnu.org To: "John Wiegley" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 01 21:04:42 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 1e9zFh-0002zh-CH for ged-emacs-devel@m.gmane.org; Wed, 01 Nov 2017 21:04:41 +0100 Original-Received: from localhost ([::1]:57524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9zFo-0005g6-NX for ged-emacs-devel@m.gmane.org; Wed, 01 Nov 2017 16:04:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9zFF-0005ej-TT for emacs-devel@gnu.org; Wed, 01 Nov 2017 16:04:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9zFF-0001yW-0s for emacs-devel@gnu.org; Wed, 01 Nov 2017 16:04:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9zF9-0001uk-51; Wed, 01 Nov 2017 16:04:07 -0400 Original-Received: from [176.228.60.248] (port=2431 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e9zF8-00015v-7M; Wed, 01 Nov 2017 16:04:07 -0400 In-reply-to: (johnw@gnu.org) 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:219854 Archived-At: > From: "John Wiegley" > Date: Wed, 01 Nov 2017 11:12:02 -0700 > Cc: Emacs developers > > 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. I agree. I would even say it more bluntly: I don't believe the current threading code can be extended to pre-emptive threads so easily. Much more redesign and reimplementing of several core internals will be needed before it will become possible to write reliable programs with pre-emptive threading. How do I know? by the amount of gray hair we needed to acquire and the amount of sweat and blood we invested before the current much simpler model got to what we have now, which is still not perfect even for the limited features it was supposed to support. > (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. I think we currently lack intermediate infrastructure to make writing such programs easily. Right now, a Lisp programmer who wants to take advantage of these features needs to jump through many hoops and overcome some counter-intuitive/surprising obstacles and issues. Volunteers, where are you?