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.
[1] This issue may come from accidental misuse of terminology, but it's an
important distinction.
Missing reference to footnote.
--
error compiling committee.c: too many arguments to function
