tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: next vforkup chapter: lwpctl

On Mon, Feb 14, 2011 at 9:35 AM, Thor Lancelot Simon <> 
> 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)?

Home | Main Index | Thread Index | Old Index