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