Re: "concurrency" branch updated

[David Kastrup]

John Wiegley <address@hidden> writes:

>>>>>> Ken Raeburn <address@hidden> 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