On 21/12/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
>>p.s. vfork() is a different beast. Here a child is supposed to call
>>exec*() rigth after fork() so it's allowed to "borrow" parent's
>>address space (vm_struct -> all vm_area(s)) and the parent is blocked
>>in the mean time. As a result, no need for copy-on-write.
>
>
> I think to remember that glibc vfork is just fork.
At least, linuxthread's vfork is the same as linuxthread's fork.
Well, I'm looking at glibc-2.3 :
1) ./sysdeps/unix/sysv/linux/i386/vfork.S
- if there is a vfork syscall - it's used, otherwise - fork.
- If per-arch code doesn't provide an implementation, the generic (
== notmal fork() ) is used.
2) linux (I'm looking at 2.6.12.6) does provide a separate vfork()
(sys_vfork => do_fork() with additional flags CLONE_VFORK | CLONE_VM).
And it looks like it works as it should be in theory (at least briefly
following the CLONE_VFORK logic in do_fork() and knowing that CLONE_VM
is used for threads to share a vm_struct).
Anyway, I was refering to vfork() as it should be in theory in the
context of copy-on-write policy.
Indeed, your remarks make sense. We should know when Markus conducts
the tests suggested by Philippe. Although, the use of fork() in
multi-threaded applications is sometimes tricky. I do remember once I
had a problem but just can't recall any details (just that it was
memory leaks :)
--
Gilles Chanteperdrix
--
Best regards,
Dmitry Adamushko
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
