Paul Davis wrote:
>
> >Would you bet some money with me that if divide the two part I get the
> >very same results?
>
> US$0.05
You've a debt, I've tried this morning ;-)
> >I repeat myself: it's a way to compute the extra cost to have multiple
> >process (thread implementation in linux is done with processes as you
> >already know)
>
> NO, ITS NOT!
>
> Its done with the clone(2) call, which happens to be the basis of
> fork(2) as well as pthread_create(3). But the options to clone used by
> pthread_create() mean that every new kernel thread uses the same
> address space as the parent, meaning that context switches between two
> threads in the same process does not incur a TLB flush. a kernel
> thread is not a process when viewed from the perspective of the VM
> system and its cache/TLB interactions.
*This* is an argument! I'll add multi-process part to ctx.c as soon I
find some time.
> >"Before an xrun has occured"??? Of course not... I was thinking to
> >something far less ambitious. A component does not answer any more? We
> >disable it/kill it/restart it. The one process model imply that all the
> >application need to be restarted.
>
> How do you propose to detect that a component has not answered? Think
With a timer on engine.
> about it for a little while, and I think you'll see that the way you
> would do this with a multithreaded app is not very different than the
> way you'd do it with a multiprocess design.
And so what?
I've written that *single thread* approach is more fragile under this
point of view.
In order of increasing robustness:
- single thread
- multiple threads
- multiple processes
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
