>>> 1) state machines with a thread pool to make blocking functions >>> asynchronous (what we have today) >>> >>> 2) co-operative threading >>> >>> 3) pre-emptive threading
> > On a philosophical note, threads may be easier to model complex > > hardware that includes a processor, for example our scsi card (and how > > about using tcg as a jit to boost it :) > > Yeah, it's hard to argue that script evaluation shouldn't be done in a > thread. But that doesn't prevent me from being very cautious about how > and where we use threading :-) I agree that making script execution asynchronous is a good thing, however I'm not convinced that (3) is the best way to do this. It's certainly the most flexible model, however it also places responsibility for locking/correctness on the device developer. A more limited scheme (e.g. asynchronous callbacks) can actually be significant advantage. By forcing the developer to solve the problem in a particular way we significantly reduce the scope for race conditions, and hopefully restrict all locking concerns to common code/APIs. Paul [1] This issue may come from accidental misuse of terminology, but it's an important distinction.
