> This is exactly why we call it dangerous: We have 2nd order ignorance > about thread safety in the CMU CL code base. Most of the code in the code > base was written against a world where there was no preemptive parallelism > at the sub-lisp-primitive level. Auditing the code base for places which > need locking and/or other synchronization primitives added is yet to > happen.
Why not have "preemptive" multitasking by having the CommonLisp compiler insert "yields" into the code it outputs? This could be done with just a few percent overhead (a single register compare every hundred instructions on the average). It would ensure that only code that knows about preemption would be preempted. Of course, it would not result in guaranteed response times, but the more code is compiled with it, the better. As for native threads, I think hoping to ever fix everything at once is probably not going to work. Most languages move from non-threaded to natively threaded by adding the capability to use native threads and providing just a minimal set of functions callable from threads (very few system calls and almost no library calls are guaranteed to work from anything other than the main thread). That then gives people the incentive to fix things as they go along. For better safety, library functions could be marked for thread safety and the runtime could throw an error if unmarked functions are called from the wrong context. Tom __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
