Re: (Fwd) Re: includes inside squid.conf

From: Andres Kroonmaa <>
Date: Wed, 3 Apr 2002 17:27:41 +0300

On 3 Apr 2002, at 12:17, Henrik Nordstrom <> wrote:

> On Wednesday 03 April 2002 11:43, Robert Collins wrote:
> > If they have a really efficient fork(), then do we care? :].
> Exacly. And is what all modern OS:es have except for the small detail
> about temporary swap allocation (not use).

 I've been trying to find out whether Solaris has changed its fork
 to more efficient. If it has then its no point in pursuing vfork,
 as so far all that I have found is warnings against using it and
 Solaris is notoriously slow to change such things. I'd bet it to
 be last one. ;/ Even Solaris man says don't use it, it will be
 eliminated in future.

> > > c) Things crash an burn if the child receives a signal between
> > > vfork() and execve().
> >
> > Why would a child receive a signal? (Other than sigsegv or
> > something similar, which will make anything crash and burn).
> Who knows..

 Thats probably OS dependant. Solaris claims to specifically deal
 with possible deadlock situation arising from signals during vfork.

> > > d) There is no directly clean way to handle a failed execve()
> > > when vfork() is used.
> >
> > What about the return code from _exit() ? That's then seen by the
> > parent in the wait() call.
> except for the small detail of errno and possibly other shared data
> touched by execve() when it fails. Because of this the situation in
> the parent is slightly undefined upon a failed execve in the child.
> In a normal "plain" application this is usually safe, but if the
> application compiled with threading enabled (such as Squid often is)
> then errno is not always safe to update in a vfork()..

 vfork should spawn only single thread, ie. caller thread. This means
 that only main thread shares errno with vfork child. This should be
 managable, especially because main thread is suspended while vfork
 runs. And errno must be virtualised in threaded app anyway.

> Note: As you probably know you are not allowed to use any of the
> other exec() calls in a vfork. Only execve can be used as this is the
> only form where everything is prepared by the caller.

 Solaris for eg. allows any call from exec family, at least by manpage.

 Anyway, has anyone ever seen encouraging of use of vfork for anything
 other than fast { vfork; execve; }? I get impression that we shouldn't
 bother with vfork unless we can strip code down to almost nothing
 needed between vfork and exec...

 perhaps indeed try to create a special service process that spawns
 all needed stuff for Big squid per request.

 Andres Kroonmaa <>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Wed Apr 03 2002 - 07:34:44 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:57 MST