On Wed, 11 Jun 2003, David Lichteblau wrote: > > 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. I thought we changed the timeouts so that this wasn't as much of a problem. > > 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?)
I can't speak to the status of the SBCL threads package, but the CMUCL package isn't that terrible for a "cooperative" threads package. Sometimes interrupts leave you in the debugger in an unexpected thread, and there are certainly other rough edges, but it's quite useful for getting real work done. Certainly adopting Dan's SBCL work, in whole or in part, is well worth considering. Tim
