On 2012/08/16 07:57, David Xu wrote:
On 2012/08/16 01:46, Konstantin Belousov wrote:
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
You are requiring the thread library to implement such a mutex
and other locks, that after vfork(), the mutex and other lock types
must
still work across processes, the PTHREAD_PROCESS_PRIVATE type of
mutex and other locks now need to work in a PTHREAD_PROCESS_SHARE
mode.
In fact, yes. In my patch I achieve this by single-threading the parent,
I still think single-threading is execussive, vfork should be fast, and
because parent thread is already waiting for child process, there
is no problem to reuse the parent's stack in child process, it is
compatible.
which means that existing _PRIVATE mutexes are enough.
Well, you forget that if private mutex sleep-wakeup queue is in kernel,
you only can see it in same process, otherwise it is a security problem.
Now It works because it is me implementing umtx in such a way that it
comparings two vmspace pointers in kernel umtx code, and treat two
threads are in same process if they are same. But there are
implementations
do not work in this way, they simply look up lwpid in same process,
and if
not found, the mutex is broken. process-private and proecess-shared locks
work in very different way, then your assumptions is false.
I must say my implementation is a lucky, not is the intention.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
