Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Aug 2012 08:06:58 +0800
From:      David Xu <listlog2011@gmail.com>
To:        davidxu@freebsd.org
Cc:        Konstantin Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org, Jilles Tjoelker <jilles@stack.nl>
Subject:   Re: system() using vfork() or posix_spawn() and libthr
Message-ID:  <502C39A2.7010608@gmail.com>
In-Reply-To: <502C3775.8090401@gmail.com>
References:  <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> <20120815174609.GM5883@deviant.kiev.zoral.com.ua> <502C3775.8090401@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?502C39A2.7010608>