If I understand correctly exit(status) performs a user-level cleanup
and _exit performs a kernel level cleanup.
Why can't we have exit call to internally call _exit ,this way in one
shot we do a user-level and kernel-level cleanup?
Is there any other alternative call to do such a cleanup?

Regards,
Rajendra S.

[ Post a follow-up to this message ]

On Mon, 11 Jul 2005 11:50:38 +0400, Rajan <rstalekar@yahoo.com> wrote:

> If I understand correctly exit(status) performs a user-level cleanup
> and _exit performs a kernel level cleanup.

Not quite. Please refer to
http://www.opengroup.org/onlinepubs...tions/exit.html

--
Maxim Yegorushkin
<firstname.lastname@gmail.com>

[ Post a follow-up to this message ]

Rajan wrote:
> If I understand correctly exit(status) performs a user-level cleanup
> and _exit performs a kernel level cleanup.
> Why can't we have exit call to internally call _exit ,this way in one
> shot we do a user-level and kernel-level cleanup?
> Is there any other alternative call to do such a cleanup?

exit(status) calls any at_exit functions, flushes FILEs, and then
calls the system's _exit(), AFAIK.  That means that files are
closed and the process gets freed.

So I think exit() does exactly what you want.

--
By claiming a patent [...], I'm saying that you are not permitted
to use your own knowledge to further your ends. By what right?
Roderick T. Long

[ Post a follow-up to this message ]

Whatever you thought is not what the UNIX faq says, see the link below
http://www.erlenstar.demon.co.uk/unix/faq_2.html

It says :-
The basic difference between exit() and _exit() is that the former
performs clean-up related to user-mode constructs in the library, and
calls user-supplied cleanup functions, whereas the latter performs only
the kernel cleanup for the process.

[ Post a follow-up to this message ]

Rajan wrote:
> Whatever you thought is not what the UNIX faq says, see the link below
> http://www.erlenstar.demon.co.uk/unix/faq_2.html
>
> It says :-
> The basic difference between exit() and _exit() is that the former
> performs clean-up related to user-mode constructs in the library, and
> calls user-supplied cleanup functions, whereas the latter performs only
> the kernel cleanup for the process.

"man 2 _exit" says:
"Most C programs call the library routine exit(3), which flushes
buffers,
closes streams, unlinks temporary files, etc., before
calling _exit()."

So in most cases you'll just call exit() for convenience.

--
By claiming a patent [...], I'm saying that you are not permitted
to use your own knowledge to further your ends. By what right?
Roderick T. Long

[ Post a follow-up to this message ]

"Rajan" <rstalekar@yahoo.com> wrote:
>Whatever you thought is not what the UNIX faq says, see the link below
>http://www.erlenstar.demon.co.uk/unix/faq_2.html
>
>It says :-
>The basic difference between exit() and _exit() is that the former
>performs clean-up related to user-mode constructs in the library, and
>calls user-supplied cleanup functions, whereas the latter performs only
>the kernel cleanup for the process.

Whatever you thought, the FAQ gives you additional background
information, answering specific questions, but does *not* define
the C language.  You are reading far more into the FAQ than it
says.  But worse you are ignoring documentation that does intend
to be the complete definition.

Read the man pages for exit(3) and _exit(2), and first take note
that (as befits what the FAQ says) exit() is in Section 3 and
_exit() is part of Section 2.

There are two other items to note.  One is that the man pages
provide significantly more information, in distinctly pedantic
terminology, than does the FAQ.  That is of course the
distintion between a man page and a FAQ.  Second is that both
functions conform to the ANSI/ISO C Standard; and hence that
document should also be consulted if you want the definitive
statement on what those two functions must do.  (See Sections
7.20.4.3 and 7.20.4.4.)

Specifically, one statement in the C Standard needs to be
emphasized, if you want to understand the statements in the FAQ:

2 The exit function causes normal program termination to
occur. If more than one call to the exit function is
executed by a program, the behavior is undefined.
7.20.4.3  ISO/IEC 9899:1999 (E)

That is why _exit(2) is necessary.  If a program forks and
both resulting processes call exit(3), the result is undefined
behavior.

--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

[ Post a follow-up to this message ]

In article <87acktid9s.fld@barrow.com>, Floyd L. Davidson wrote:
> Specifically, one statement in the C Standard needs to be
> emphasized, if you want to understand the statements in the FAQ:
>
>    2 The exit function causes normal program termination to
>      occur. If more than one call to the exit function is
>      executed by a program, the behavior is undefined.
>          7.20.4.3  ISO/IEC 9899:1999 (E)
>
> That is why _exit(2) is necessary.  If a program forks and
> both resulting processes call exit(3), the result is undefined
> behavior.

You are making the classical mistake of quoting the C standard to make a
POSIX/UNIX point (POSIX also says that multiple calls to exit() result
in undefined behavior, but I think you're misinterpreting this
statement, see below.)

Since every process besides init is a descendent of another process, no
Unix program could ever call exit() according to your logic. The POSIX
standard indeed says that repeated calls will yield undefined behavior,
but this is to be interpreted in the context of a single process.
Multiple calls to exit() can happen even in a single-threaded and single
process plain ISO C program if an exit handler calls exit() again:

#include <stdlib.h>

void
handler(void) {
exit(0); /* Whoops, called again! */
}

int
main(void) {
(void) atexit(handler);
exit(0); /* or return 0; */
}

Sharing of your exit handlers across fork() (but of course not across
exec!) will likely yield problems, but it is not illegal to do so. A
worse problem is the flushing of stdio buffers; You will probably get
some data twice if you don't fflush(NULL) before fork().

--
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
... but I'm not speaking for the Software Libre Foundation!

[ Post a follow-up to this message ]

Seems I was too quick to reply again.

In article <3jfm54Fprtc0U1@individual.net>, Nils Weller wrote:
> In article <87acktid9s.fld@barrow.com>, Floyd L. Davidson wrote:
> Unix program could ever call exit() according to your logic. The POSIX
> standard indeed says that repeated calls will yield undefined behavior,
> but this is to be interpreted in the context of a single process.

The standard literally says:

If exit() is called more than once, the behavior is undefined.

I now think this is not a matter of interpretation at all.

Apologies.

(Still, however, the *C* standard says what it says because of exit
handlers.)

--
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
... but I'm not speaking for the Software Libre Foundation!

[ Post a follow-up to this message ]

Nils Weller <me@privacy.net> wrote:
>In article <87acktid9s.fld@barrow.com>, Floyd L. Davidson wrote: 
>
>You are making the classical mistake of quoting the C standard to make a
>POSIX/UNIX point (POSIX also says that multiple calls to exit() result
>in undefined behavior, but I think you're misinterpreting this
>statement, see below.)

But which *defines* those two functions?   The C Standard, not POSIX.

We may indeed be discussing it in the context of a POXIX platform,
but that is not required, and the same points apply to non-POSIX
platforms.

>Since every process besides init is a descendent of another process, no
>Unix program could ever call exit() according to your logic. The POSIX

That is not true.  See below.

>standard indeed says that repeated calls will yield undefined behavior,
>but this is to be interpreted in the context of a single process.
>Multiple calls to exit() can happen even in a single-threaded and single
>process plain ISO C program if an exit handler calls exit() again:

That may be what it is referring to, and I did consider which it
might be.  Given the effect of calling exit(3) from both processes
of a forked program, I think it applies.  (Not to mention that C
has no concept of processes or of fork().)

>Sharing of your exit handlers across fork() (but of course not across
>exec!) will likely yield problems, but it is not illegal to do so. A

Exactly.  A call to exec() starts a *different* program.  (In a
hosted environment, it begins execution of startup code and
calls a main() function.)

>worse problem is the flushing of stdio buffers; You will probably get
>some data twice if you don't fflush(NULL) before fork().

You might also delete files with the first exit() that are still
required by the other process.

--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

[ Post a follow-up to this message ]

In article <87acktgrag.fld@barrow.com>, Floyd L. Davidson wrote:
> Nils Weller <me@privacy.net> wrote: 
>
> But which *defines* those two functions?   The C Standard, not POSIX.
> We may indeed be discussing it in the context of a POXIX platform,
> but that is not required, and the same points apply to non-POSIX
> platforms.

First of all, to tell you the ashaming truth: I didn't read your entire
post before I replied. I read the first paragraph, then got bored by the
man pages and FAQ stuff (I have read enough man pages and FAQs), and
jumped straight to your C standard citation.

Had I read the preceding paragraphs, I would have noticed this false
premise of yours:
 

_exit() is NOT an ISO C function (C99 introduces _Exit() however), which
is in part why I was so irritated with your citation.

But what's far more important is that we are talking about undefined
behavior. POSIX does a great job at avoiding incompatibilities with ISO
C - Defining undefined behavior, however, does not constitute an
incompatibility!

In fact there are many places where POSIX uses undefined behavior as a
backdoor to introduce useful functionality and you probably encounter
(and benefit from!) some of them every day. For instance, writing

#include <unistd.h>

... (without providing unistd.h yourself) invokes undefined behavior in
C, but not in POSIX. fflush(stdin) invokes undefined behavior in C, but
not in POSIX. That does not make POSIX itself incompatible with C; It
just means that your code is no longer C if you execute a construct that
is defined by POSIX but not by ISO C. There would be absolutely no
incompatibility if POSIX said that it is okay to call exit() more than
once, which is why we had to refer to POSIX to determine the legality of
this construct.
[vbcol=seagreen] 
>
> Exactly.  A call to exec() starts a *different* program.  (In a
> hosted environment, it begins execution of startup code and
> calls a main() function.)

Agreed, let's move on.
 
>
> You might also delete files with the first exit() that are still
> required by the other process.

True, but you get the buffering effect ``for free'' even if you only use
stdout, which is why it is arguably more dangerous for the unwary (as
far as I'm concerned the whole question is [or was] about legality
anyway, not usefulness, since I never call exit() twice.)

(Sorry again about not reading the whole post; I usually only mean to
say what I say with regards to the text I quote. The fact that I only
respond to part of a post does not mean that I approve of the rest. I
will be more careful in the future.)

--
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
... but I'm not speaking for the Software Libre Foundation!

[ Post a follow-up to this message ]