Email list hosting service & mailing list manager

Comments on SRFI-39 shivers@xxxxxx (26 Jan 2003 08:45 UTC)
Re: Comments on SRFI-39 Matthew Flatt (26 Jan 2003 14:10 UTC)
Re: Comments on SRFI-39 sperber@xxxxxx (26 Jan 2003 15:38 UTC)
Re: Comments on SRFI-39 Richard Kelsey (11 Feb 2003 15:58 UTC)
Re: Comments on SRFI-39 bear (11 Feb 2003 16:16 UTC)
Re: Comments on SRFI-39 Richard Kelsey (11 Feb 2003 16:56 UTC)
Re: Comments on SRFI-39 Marc Feeley (13 Feb 2003 01:38 UTC)
Re: Comments on SRFI-39 Richard Kelsey (13 Feb 2003 02:30 UTC)
Re: Comments on SRFI-39 sperber@xxxxxx (13 Feb 2003 12:47 UTC)

Re: Comments on SRFI-39 Richard Kelsey 11 Feb 2003 16:55 UTC

   Date: Tue, 11 Feb 2003 08:16:06 -0800 (PST)
   From: bear <xxxxxx@sonic.net>

   Are winding continuations a la R5RS *compatible* with threads?

I don't understand.  It is easy to implement non-preemptive threads
in R5RS using winding continuations.  Given some form of timer
interrupt you can do preemptive threads.  How can a program written
in R5RS be incompatible with it?

Problems only appear when you try to weave threads into the existing
R5RS mechanisms, as the combined SRFI 18 and SRFI 39 do, instead of
either building threads on top of R5RS or making them an orthogonal
addition.

   To me it looks like if you have non-blocking I/O and call/cc with
   winding continuations, you don't need threads.

Sure, because you can use them to implement threads.

   And if you want
   dynamic state maintained for safety by winding continuations, you
   can't have threads of the kind you're talking about without some
   fundamentally new state-maintenance operations that can handle
   arbitrary multiple points of program execution simultaneously.

The problem is with the state, not with the continuations or the
winding.  If you share state between threads you needs some form of
synchronization mechanism.  This is not news.

                                        -Richard