Re: next vforkup chapter: lwpctl

[Garrett Cooper <yanegomi%gmail.com@localhost>]

On Mon, Feb 14, 2011 at 9:35 AM, Thor Lancelot Simon <tls%panix.com@localhost> 
wrote:
> On Mon, Feb 14, 2011 at 03:33:03PM +0200, Antti Kantee wrote:
>> On Mon Feb 14 2011 at 14:27:10 +0100, Joerg Sonnenberger wrote:
>> > On Mon, Feb 14, 2011 at 03:16:11PM +0200, Antti Kantee wrote:
>> > > The following patch makes a vfork child update the parent's lwpctl area
>> > > while the child is running.  Comments or better ideas?
>> >
>> > I think this is a very good case of "don't do that". malloc after
>> > vfork() is just wrong. If rumphijack internally forces that for normal
>> > system calls, it should downgrade vfork() to fork().
>>
>> This is not about rumphijack.  Look at e.g. sh and make.
>>
>> Even if you do fix them, it's not just limited to malloc either.
>> Anything that uses LWPCTL will be screwed up after vfork.
>
> But what, that uses LWPCTL, are you actually supposed to be doing after
> vfork()?  Whack some environment variables and some globals -- maybe -- then
> exec*().  What else is legitimate?
>
> If it doesn't slow down vfork, great, fix whatever.  But vfork performance
> really is critical.  Look how much slower, for example, FreeBSD builds
> the system than we do.  vfork is a huge part of that.

Hi Thor,
    Do you have performance metrics to back up your statement below
about `FreeBSD build[ing] the system slower than we do' (paraphrased)?
Thanks,
-Garrett