On Fri, 2006-12-22 at 11:27 +0100, M. Koehrer wrote: > Hi Gilles, > > > fault_vm is safe to use only if you are calling fork at a time when > > there is only one thread. So, if your application is forking at init, it > > should be OK. > Do you mean there must be only one real time thread? > That means, when I have an application that creates multiple real time > threads, > I can not rely on fault_vm() ? > In this case I have to do the "hard" way by using a different (non real time) > context to do the forks and system() calls. > As this is hard to understand, I strongly recommend that there is Xenomai > support > for this! I.e. a Xenomai API that can be called with a (callback-)function > pointer and > a user data pointer. > When a (realtime) thread calls this function, the real time thread is > blocked. > The callback function is then called from a safe context and > after exit of the callback function the real time thread is resumed. >
Sorry, but no, no way, I won't merge anything like this, ever. This is the wrong way to go. The right way is to fix the COW issue at kernel level - probably the I-pipe has to provide the required support - because this is where those dirty details belong to. This is definitely not an API issue, because you just cannot tell application developers to care about arch-specific VM issues when using a so-called generic API that has to work the same way on all archs (e.g. MMU-less platforms don't care about this, others would). What could be considered as a bearable limitation right now must not have any impact on long-term principles, and the API stuff belongs to that category of issues. > Regards > > Mathias > > > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
