Gilles Chanteperdrix wrote: > Dmitry Adamushko wrote: >> On 22/12/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote: >> >>> In absence of a better solution, I would recommend to use the "fault_vm" >>> function after each fork. >> >> But it's not safe. It doesn't stop any other rt threads (if there are >> a few in this app.) from touching the wp-pages (it's not only about >> stacks after all) in the mean time. So fault_vm() only increases the >> probability of not-crashing but doesn't eliminate it completely. >> >> So all the contextes have to be blocked starting from the moment >> fork() is about to be called and till the moment a subsequent >> fault_vm() is done. >> It's ugly and that suggests fork() is not ok here at all. >> >> And btw, vfork() should be a funny thing being called from >> multi-threaded app. It blocks a calling context and borrows its >> address space while other threads are continuing to run, well, with >> the same context (maybe it's handled somehow, have to check). > > 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. >
Isn't there something to do about it at kernel level, i.e. on cloning the mm-context of a process? Could we somehow force an immediate copy of a real-time process's mm?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
