I have been twiddling some with the wording of the concurrency guarentees and want to run them by the list. the rules I am thinking of adding are: * every runnable thread is guarenteed to run in a finite amount of time if a program reaches a yield-point infinitly often. * Foreign concurrent calls, handle IO, and all IO actions that directly interact with the world outside the current process all must be yield-points. (in addition to any yield-points implied by the progress guarentee) The first rule is just to rule out completely brain-dead schedulers and give a fairly useful fairness guarentee. (in fact, I think it subsumes the preemptive fairness guarentee as written, as a preemptive implementation does reach a yield-point infinitly often independently of what the program is doing) I originally thought the progress guarentee implied the second, but I realize that is somewhat UNIX-centric in that all IO must be treated as potentially blocking. however in an embedded system where for instance you write directly to the screen buffer rather than a file descriptor this might not be the case so we should probably be more clear. I would like to avoid enumerating the yield points explcitly, except perhaps as a guide saying "these library routines are examples of those in the standard library that must be yield-points according to the standard". Coming up with a rule rather than a list will make it easier for users to think about and give guidance (though of course we can't guarentee) where yield-points should be placed in any implementation provided extensions. I don't intend to imply things like all memory access in case it is in an memory mapped IO region or anything that changes CPU load because someone might be looking at your CPU usage in /proc should be yield-points, just those IO actions that "explicitly" interact with the outside world. for the correct definition of explicitly. :) John -- John Meacham - ⑆repetae.net⑆john⑈