> On 04/01/2010 04:14 PM, Paul Brook wrote: > >>> 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. > > Can you elaborate? When would the callbacks be called? When would the > callbacks yield back? If the script isn't run to completion (a halt instruction), there isn't really a good answer to these questions.
In practice I don't think pre-emtive multithreading actually solves all that many problems. If a script enters an indefinite loop then you want to be terminating or throttling it anyway. The difference is whether you yield/return or drop locks and performing a blocking operation. I suppose what I'm getting at is the difference between explicit multithreading and event based programming. In the latter case I believe it's much easier to have individual devices use a sequential model, but have the whole system be concurrent. > > [1] This issue may come from accidental misuse of terminology, but it's > > an important distinction. > > Missing reference to footnote. I was going to comment on the difference between re-entrancy and concurrency, but decided against it. Paul
