Steve Lawrence wrote:
> It seems to me that the first comment in the NOTES section of fork(2) would
> only apply to vfork().
It's true that the comment that exit() will damage the parent's stdio
data structures applies only to the vfork() case. However, you should
still call _exit() even in the fork() case.
The reason why you need to call _exit() in the fork() case is to protect
the files that underlie the parent's stdio structures. The fork()'ed
child has an exact copy of the parent's file descriptors and in-progress
stdio buffers. Calling exit() in the child will have the side effect of
fflush()'ing the child's copies of those buffers, which will corrupt any
of the parent's files that were open for write and had stdio-buffered
data pending for those files.
Mike.
--
[EMAIL PROTECTED]
> On Fri, May 23, 2008 at 01:31:58PM +0200, Joerg Barfurth wrote:
>> Hi,
>>
>> I just stumbled over this:
>>
>> Edward Pilatowicz schrieb:
>>> - nit: in start_zoneadmd(), instead of:
>>> if ((child_pid = fork()) == -1) {
>>> zperror(gettext("could not fork"));
>>> goto out;
>>> } else if (child_pid == 0) {
>>> ...
>>> _exit(1);
>>> } else {
>>> ...
>>> }
>>> how about:
>>> if ((child_pid = fork()) == -1) {
>>> zperror(gettext("could not fork"));
>>> goto out;
>>> }
>>>
>>> if (child_pid == 0) {
>>> ...
>>> _exit(1);
>>> }
>>>
>>> ...
>>>
>>> - nit: we have direct bindings now. :) so why bother with:
>>> _exit(1)
>>> instead just call:
>>> exit(1)
>>>
>> Beware: _exit() is not just a linker synonym for exit(). See the exit(2)
>> man page for differences. When fork-ing without exec, calling _exit is
>> the proper way to exit; see the Notes section in the fork(2) man page.
>>
>> - J?rg
>>
>> --
>> Joerg Barfurth phone: +49 40 23646662 / x66662
>> Software Engineer mailto:[EMAIL PROTECTED]
>> Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/
>> Thin Client Software http://www.sun.com/software/sunray/
>> Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
>>
>>
>> _______________________________________________
>> zones-discuss mailing list
>> zones-discuss@opensolaris.org
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> zones-discuss mailing list
>> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
