[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Threa
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU |
Date: |
Thu, 1 Apr 2010 13:14:24 +0000 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; ) |
>>> 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.
- Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU,
Paul Brook <=