<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 9:02 AM, Nedko Arnaudov <span dir="ltr"><<a href="mailto:nedko@arnaudov.name" target="_blank">nedko@arnaudov.name</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div>What about designing "plugins" that can run either in-process or<br>
out-of-process?</blockquote><div><br><br></div><div>AFAICT that implies either a new plugin API or use of a plugin host, and we already have the latter.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 If the multiclient app support in jack is improved, </blockquote><div><br></div><div>i don't see how multiclient app support is relevant here. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
jack<br>
can route either "plugins" or "apps". The system can be even designed so<br>
that the plugin/app mode is switchable on the fly, without single xrun.<br></blockquote><div><br></div><div>i think this displays a certain simplification of what plugin hosting actually requires in the real world.<br></div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is true that it is good to have bugless software, but the reality is<br>
that bugs will always exist and the system can be made less error<br>
prone. </blockquote><div><br></div><div>errors are one thing, bugs are another. bugs exist in many of the thousands of win/VST plugins out there, and the majority solution to this problem is a simple one: people stop using them and/or become very aware of what triggers the bug(s). having developer A create a somewhat baroque new architecture in order to fix issues with developer's B code just doesn't seem smart to me. oh wait,  i just described JACK ....<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And most importantly, user experience may vary, so it is best to<br>
allow (not force) user to choose whether to pay some CPU load in<br>
exchange of better system stability.<br></blockquote><div><br></div><div>in this context, it is not us but the OS that forces the user to make this choice. if you want a segfault in a plugin to NOT reduce host stability, you have to run it out of process. if you run it out of process, you pay the price of more CPU load. if the OS provided some way to "partition" or "sandbox" a shared object within a process, perhaps one could get away without being forced to make this choice. but no OS that i am aware of can do this for native code.<br>
</div><div> <br></div></div></div></div>