From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: "concurrency" branch updated Date: Thu, 05 Nov 2015 15:17:11 +0100 Message-ID: <877flwv8d4.fsf@fencepost.gnu.org> 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 1446734427 19736 80.91.229.3 (5 Nov 2015 14:40:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 14:40:27 +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 15:40:26 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 1ZuLiB-0007zg-W0 for ged-emacs-devel@m.gmane.org; Thu, 05 Nov 2015 15:40:24 +0100 Original-Received: from localhost ([::1]:32790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLiB-0003Jf-DU for ged-emacs-devel@m.gmane.org; Thu, 05 Nov 2015 09:40:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLi7-0003Iz-63 for emacs-devel@gnu.org; Thu, 05 Nov 2015 09:40:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuLi5-0003iR-7h for emacs-devel@gnu.org; Thu, 05 Nov 2015 09:40:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLi5-0003iN-3m; Thu, 05 Nov 2015 09:40:17 -0500 Original-Received: from localhost ([127.0.0.1]:36919 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZuLhx-0006Kh-AK; Thu, 05 Nov 2015 09:40:09 -0500 Original-Received: by lola (Postfix, from userid 1000) id C14F6DF976; Thu, 5 Nov 2015 15:17:11 +0100 (CET) In-Reply-To: (John Wiegley's message of "Thu, 05 Nov 2015 08:17:13 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:193301 Archived-At: John Wiegley writes: >>>>>> 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. It depends on what "upgrading" means. For example, Lua offers "coroutines" which are basically not more than independent stacks but not parallel execution: the corresponding functions, "yield" and "resume" both _take_ and _return_ values. Essentially, this is used as a control flow mechanism similar to function calls and returns, with the difference that such "functions" do not lose their place and local variables when "returning" but continue upon resuming. Since the switching of threads is accompanied by a passing of values, executing such threads in parallel is not an option and thus there are no concurrency issues. I've used this kind of control flow (basically swapping in a different stack and returning) in terminal emulators written in assembly language to good effect: code becomes much more readable if the various code paths interpreting terminal control sequences can just "call" the user program for additional characters (where "call" means returning to the user program and laying dormant until the terminal emulator gets called with the next character) without losing the place in the logic of the terminal emulator. This kind of stack swap is not the same as true multithreading. It definitely has interesting applications with regard to things like generators and streams as it may lead to much more straightforward code than trying to maintain some internal state in closure variables queried on reentry when the most natural representation of the internal state you'd want to maintain is the current instruction and stack pointer. I think Ada has the concept of "rendezvous" for multithreading where there are well-defined synchronous parts of interaction as well as asynchronous execution. > I hope at that point it would be a fairly seamless upgrade, For some kinds of control flow application, parallelism might not even be an option. -- David Kastrup