This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
roland.kaufmann@space.at writes: > > >>>>> " " == Peder Chr Norgaard <pcn@tbit.dk> writes: > > > (Except that my need is not threads, but co-routines. Guile > > have threads, working fine for many purposes, thank you, but > > they are too heavyweight for this kind of work. Shortly, I > > want to "use call/cc to capture the part of the walking state > > that is on the stack"; if I can't get that to work, my > > alternative is not to use threads, but to capture the state > > explicitly - which means that I need to recode a piece of fine > > walking code to avoid use of recursion). > > The explanation which brought me closest to understand call/cc is > Dorai Sitaram's "Teach Yourself Scheme in Fixnum Days" > http://www.cs.rice.edu/~dorai/t-y-scheme/t-y-scheme.html > coroutines are among the examples presented there. > I found something by a certain Mr.Preprocessoer, in civil life known as Sperber , on the web, with an example of implementing coroutines. I tried to base a process simulation upon c/cc. It was horribly slow. And I never figured if it is safe to call c/cc in signal handlers, that seems to depend on many implementation details. For educational purposes it is a fine exercise though, and much easier and more elegant than in C++ (which I've seen done in a german book about oo process simulation), because c/cc wraps already stuff like longjump. M.Siskind, of Stalin fame, did even more thorough stuff in his academic teaching days and sent some to me last summer, but I might have a hard time in finding old mails now. > Are you sure that call/cc is less ``heavyweight'' than threads in > Guile? I think Guile needs to copy the entire stack each time a > continuation is captured. I think so. It was not for fun that Jim Blandy decided to add C-level support for exceptions (catch, throw), who avoid stack copying when it is not really needed. Klaus Schilling