> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@squid-cache.org]
> Sent: Wednesday, April 03, 2002 8:18 PM
> > 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).
Except for the OS with majority market share. It doesn't have an
efficient fork().
> > Why would a child receive a signal? (Other than sigsegv or
> something
> > similar, which will make anything crash and burn).
>
> Who knows..
In which case we should be willing to at least try.
> > > 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()..
Most C libraries have thread-specific errno these days, and if they
don't have that but do have kernel threading... there is a real
non-squid problem, because most C calls that set errno are not
syncronised.
errno being touched by execve is IMO explicitly allowed by the vfork
description, as execve is an allowed call.
Rob
Received on Wed Apr 03 2002 - 03:40:46 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:57 MST