This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
All interesting discussions aside... It would be nice if the SRFI stated explicitly what we all hope and assume: that a continuation captured by one thread can be invoked by other threads. One could argue that it should be obvious --- after all, we don't have to specify that `car' still works, right? However, since such a requirement would conflict with several existing call/cc implementations, many people will be under pressure to make the decision the other way. I hope the SRFI will make an explicit statement to prevent this possibility. Such a statement probably won't prevent people from creating incompatible implementations, but it will at least encourage them to recognize the incompatibilities, and warn their users. Actually, with my question about memory coherence, I guess I really am asking the SRFI to specify how / under what conditions `car' still works. In general, while I definitely appreciate Marc making the effort to put down a threading proposal, I feel this SRFI doesn't really address a lot of important questions about what concurrent execution really means. For example, in the absence of a disclaimer about memory coherency in the style of the POSIX or Java specs, you need to make some statement about what constitutes an "atomic" action. It's not something you can guess from the SRFI plus RnRS. Without that, I think there's a danger that the SRFI will be useful only on naive thread implementations, and provide insufficient guidance for implementors trying to support true multi-processor systems on real-world hardware.