Quoting Raymond Toy ([EMAIL PROTECTED]): > I believe thread switching is slow because it has to copy the control > (?) stack on each switch. The obvious solution is adjusting the > stack pointer to point to the new control stack, with no copying. Do > not know if this would work or not.
Sure, but not _that_ slow. IIRC delays are due to the interaction of threads with SERVE-EVENT timeouts, but I may be wrong. STARTUP-IDLE-AND-TOP-LEVEL-LOOPS initializes multiprocessing, so a standard installation of CMUCL would not want to call it. However, multiprocessing seems to be mostly useless without it. Proposal: Call it from INIT-MULTI-PROCESSING. That way it affects only users of multiprocessing, who probably want it anyway. (However, isn't sb-threads already better than CMUCL's MP package? An unfinished threads interface surely lacks robustness, but CMUCL does not have that either, does it?) David
