[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 <tls%panix.com@localhost>
> 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.
Do you have performance metrics to back up your statement below
about `FreeBSD build[ing] the system slower than we do' (paraphrased)?
Main Index |
Thread Index |