>You've a debt, I've tried this morning ;-)
paypal?
>> >"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.
which would presumably be asynchronous, since the engine is going to
be blocked waiting for the component to respond.
>> 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?
it means that you can get the same safety with a single-thread
approach.
>In order of increasing robustness:
>- single thread
>- multiple threads
>- multiple processes
i don't think there is *any* difference in robustness between single
thread and multithread. i agree emphatically that there is a huge
difference between the threaded models and the multiple process one,
which certainly makes the latter attractive.
--p
