|
Home > Archive > Unix Programming > July 2005 > exit and _exit calls
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
exit and _exit calls
|
|
|
| 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.
| |
| Maxim Yegorushkin 2005-07-11, 7:48 am |
| 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>
| |
| Ulrich Hobelmann 2005-07-11, 7:48 am |
| 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
| |
|
| 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.
| |
| Ulrich Hobelmann 2005-07-11, 7:48 am |
| 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
| |
| Floyd L. Davidson 2005-07-11, 5:53 pm |
| "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
| |
| Nils Weller 2005-07-11, 5:53 pm |
| 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!
| |
| Nils Weller 2005-07-11, 5:53 pm |
| 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!
| |
| Floyd L. Davidson 2005-07-11, 5:53 pm |
| 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
| |
| Nils Weller 2005-07-11, 5:53 pm |
| 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!
| |
| Floyd L. Davidson 2005-07-11, 8:48 pm |
| Nils Weller <me@privacy.net> wrote:
>In article <87acktgrag.fld@barrow.com>, Floyd L. Davidson wrote:
>
>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:
Had you read the man page for _exit(2), you would know better...
>
>_exit() is NOT an ISO C function (C99 introduces _Exit() however), which
>is in part why I was so irritated with your citation.
"The function _Exit is equivalent to _exit."
>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.
But of course POSIX *doesn't* say that it is okay to call exit(3) more
than once.
>
>Agreed, let's move on.
So why are you here beating this dead horse again?
>
>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.)
Same dead horse.
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| Nils Weller 2005-07-12, 5:57 pm |
| In article <87oe98g9v7.fld@barrow.com>, Floyd L. Davidson wrote:
> Nils Weller <me@privacy.net> wrote:
>
> "The function _Exit is equivalent to _exit."
That does not make _exit() an ISO C function. Ten years have passed in
which standard C had nothing of this sort while POSIX always had it.
> But of course POSIX *doesn't* say that it is okay to call exit(3) more
> than once.
That is irrelevant to my point, which was that undefined behavior in C
does not imply undefined behavior in POSIX (or any other add-on standard
for that matter.)
> So why are you here beating this dead horse again?
This bores me as much as it bores you. If you look at the whole thread,
you'll see that I withdrew from my initial position before you replied
the first time.
If you keep replying with stuff that I disagree with, I will also keep
replying.
--
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!
| |
| Floyd L. Davidson 2005-07-12, 5:57 pm |
| Nils Weller <me@privacy.net> wrote:
>In article <87oe98g9v7.fld@barrow.com>, Floyd L. Davidson wrote:
>
>That does not make _exit() an ISO C function. Ten years have passed in
>which standard C had nothing of this sort while POSIX always had it.
Then why put that statement into the manual?
>
>That is irrelevant to my point, which was that undefined behavior in C
>does not imply undefined behavior in POSIX (or any other add-on standard
>for that matter.)
If POSIX redefined it some different way, you'd have a valid
point.
>
>This bores me as much as it bores you. If you look at the whole thread,
>you'll see that I withdrew from my initial position before you replied
>the first time.
>
>If you keep replying with stuff that I disagree with, I will also keep
>replying.
You are beating a dead horse with something that has no value
and no meaning.
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
|
|
|
|
|