system() using vfork() or posix_spawn() and libthr

David Xu listlog2011 at gmail.com
Thu Aug 16 00:07:03 UTC 2012


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.



More information about the freebsd-hackers mailing list