From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: "concurrency" branch updated Date: Thu, 05 Nov 2015 08:17:13 -0500 Message-ID: References: <1B30AC54-4A83-4437-8BA8-B80F4ED6AF1A@raeburn.org> <831tc7vyex.fsf@gnu.org> <6918D53A-8975-404B-B81B-88939244CE7B@raeburn.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446729456 30718 80.91.229.3 (5 Nov 2015 13:17:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 13:17:36 +0000 (UTC) Cc: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 05 14:17:30 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZuKPx-0000tD-Eu for ged-emacs-devel@m.gmane.org; Thu, 05 Nov 2015 14:17:29 +0100 Original-Received: from localhost ([::1]:60599 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKPw-0001JW-U3 for ged-emacs-devel@m.gmane.org; Thu, 05 Nov 2015 08:17:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKPu-0001JQ-25 for emacs-devel@gnu.org; Thu, 05 Nov 2015 08:17:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuKPt-0002tm-7n for emacs-devel@gnu.org; Thu, 05 Nov 2015 08:17:26 -0500 Original-Received: from mail-yk0-x236.google.com ([2607:f8b0:4002:c07::236]:32968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKPo-0002ri-J2; Thu, 05 Nov 2015 08:17:20 -0500 Original-Received: by ykdv3 with SMTP id v3so39470162ykd.0; Thu, 05 Nov 2015 05:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=VOeEvIJXo3tzi9crVer3/pu0SSgrf0xgCRGfVE6EqzI=; b=LJHGEZTKpHPzNumh7HJY/bzGUwNBeoaROYkf1oBtska86sP8DLtNnmwV6IbKhzwf+y jsQOanvL4Hxm1r63+TjCJ6mQDMHVyb685O0bEQ+ltXQLopSn/0ziBX6PifngznlOgpAv STinPua23vv4VT1I1OgUCOBHuBLc64rSGfkGzcUkFa/7qktbRT2ekTTSP0NKs0ycqVT6 pTfxEwDULFgJPeJ6uQJcmOFbxT4CRVxqweJ/ZzKwm5jARhaX0rX2103oQPOD/+O0FmWT Pat2vmav1g8wr8JGvGbHJowo0JVEmjPO6WLCg6QGCy9pRdeDps64hNUAGt2fM2sMSgSE SoWA== X-Received: by 10.31.142.142 with SMTP id q136mr7023369vkd.41.1446729439878; Thu, 05 Nov 2015 05:17:19 -0800 (PST) Original-Received: from Hermes-2.local ([216.57.92.130]) by smtp.gmail.com with ESMTPSA id q126sm4580950vke.16.2015.11.05.05.17.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 05:17:18 -0800 (PST) Original-Received: by Hermes-2.local (Postfix, from userid 501) id 900E948E9C0E; Thu, 5 Nov 2015 08:17:17 -0500 (EST) In-Reply-To: <6918D53A-8975-404B-B81B-88939244CE7B@raeburn.org> (Ken Raeburn's message of "Thu, 5 Nov 2015 01:29:48 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Ken Raeburn , rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193292 Archived-At: >>>>> Ken Raeburn writes: >> It seems to me that in Emacs there is no need to be able to switch threads >> except when a thread is waiting. That should make things much simpler. > I think preemptive thread switching (or real concurrent execution) is a > better place to wind up, but cooperative thread switching is a good start. I haven't had a chance to read this entire thread yet, but I wanted to chime in and agree with both Richard and Ken. I have relatively few fears about cooperative thread switching. Also, it gives us a chance to see how people deal with debugging the sorts of issues it can lead to (e.g., a backtrace from code unrelated to something you think you just did). Upgrading to preemptive switching could happen later, once we've had more experience with writing cooperative code. I hope at that point it would be a fairly seamless upgrade, and we'd have mature facilities in place to accommodate it (i.e., the ability to "stack" backtraces, to inspect the environment of inactive threads, a messaging facility between threads to avoid global mutation, etc). What I want most is to make deadlocks and race conditions naturally hard to write -- if not impossible. The rise of Heisenbugs could make our job as maintainers much more difficult. All the worst bugs in my programming career were related to preemptive threading in some way. John