DragonFly commits List (threaded) for 2008-04
Re: cvs commit: src/sys/kern kern_umtx.c src/sys/vm vm_fault.c vm_page.c vm_page.h vm_page2.h
:While this doesn't seem like a very big hack, I still wonder how we could=
: do this more elegantly. Essentially, the locking process should not los=
:e the physical page, I'd say. The newly forked process may not use this =
:lock anyways. How are other OSes dealing with this? Or are they simply =
:disallowing futexes/umutexes for inter-process locking?
I think we're kinda stuck. If a threaded program fork()'s all of
its memory must become copy-on-write to support the fork(). Both
the mutex waiters and the signalers will still be pointing to the
same memory, but it won't be the original memory.
The umtx_sleep() does ref the underlying page it sleeps on, the
page doesn't go away. But the problem is that the page becomes copy
on write after the fork and any writers then modify a new page and
not the original. So a umtx_sleep() that goes to sleep before the
fork() will be sleeping on the original backing page and not the
copy (without the messy patch I committed).
For umtx_sleep() we have a choice of sleeping on the virtual address
or sleeping on the physical address. If we sleep on the virtual address
copy-on-write doesn't effect it (there are other complications doing
that but they can be solved). But if we sleep on the virtual address
then the calls cannot be used between non-threaded processes using