Hi,
I reported the problem of
"Invoked program called _exit and yet shell prompt doesn't return"
problem several days ago.
After consulting with some friendly tips,
It turns out that the linux _exit() was closing the tty and waiting for the
tty output to drain before finishing the process cleanly.
In one of my prevous posts, I suggested that _exit() might want to
forcibly "close" the tty(s) and losing the unfinished output.
I thought this was the long tradition of popular SunOS. Well, Solaris 7
for x86 certainly closes the ttys with extreme prejudice when _exit()
is called as I suggested. But according to man page,
SunOS 4.1.4 seemed to behave differently.
I don't think one way of handling pending I/Ois better than
the other in any particular way. Pity that there doesn't
seem to be a portable way of knowing how many
characters are pending for output, etc..
In any case, the difference between the linux and other popular
OS is a little confusing.
Thanks go to Mike Coleman who suggested
I used tcflush() to flush pending input/output so that
_exit() finishes immediately.
I modified my original program and now it behaves the same on
Solaris and Linux when the exit() is called. (That is, it quits
immediately and the prompt of the calling shell appears.)
The following is what I found about SunOS 4.1.4 and SunOS 5.7 (a ka
OS part of Solaris 7).
>From the man page of SunOS 4.1.4:
--- begin quote ---
NAME
_exit - terminate a process
SYNOPSIS
void _exit(status)
int status;
DESCRIPTION
_exit() terminates a process with the following conse-
quences:
All of the descriptors open in the calling process are
closed. This may entail delays, for example, waiting for
output to drain; a process in this state may not be killed,
as it is already dying.
---... rest omitted ... ----
--- end quote ---
So linux 2.2.1[3456]'s behavior as far as waiting for the drain
to happen coincides with that of SunOS 4.1.4.
On linux, though, my process thus stuck in the drain wait could be
killed with "^C" and so in a sense it is handled better on linux.
I have no idea if such process really gets stuck and can't be killed.
On the other hand, Solaris 7 for x86 closed the ttys without regard
for the unfinished output.
>From the man page on solaris 7 for x86:
--- begin quote ---
System Calls exit(2)
NAME
exit, _exit - terminate process
SYNOPSIS
#include <stdlib.h>
void exit(int status);
#include <unistd.h>
void _exit(int status);
DESCRIPTION
... omission ...
The exit() function then flushes all output streams, closes
all open streams, and removes all files created by
tmpfile(3S).
The _exit() and exit() functions terminate the calling pro-
cess with the following consequences:
o All of the file descriptors, directory streams,
conversion descriptors and message catalogue descrip-
tors open in the calling process are closed.
If the parent process of the calling process is exe-
cuting a wait(2), wait3(3C), waitid(2) or waitpid(2),
and has neither set its SA_NOCLDWAIT flag nor set
SIGCHLD to SIG_IGN, it is notified of the calling
process's termination and the low-order eight bits
(that is, bits 0377) of status are made available to
it. If the parent is not waiting, the child's status
will be made available to it when the parent subse-
quently executes wait(2), wait3(3C), waitid(2) or
waitpid(2).
... omission . The man page has lengthened quite a bit! ....
o All open named semaphores in the process are closed as
if by appropriate calls to sem_close(3R). All open
message queues in the process are closed as if by
appropriate calls to mq_close(3R). Any outstanding
^^^^^^^^^^^^^^^
asynchronous I/O operations may be cancelled.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
o An accounting record is written on the accounting file
if the system's accounting routine is enabled (see
acct(2)).
SunOS 5.7 Last change: 28 Dec 1996 3
--- end quote ---
So Solaris 7 for x86 seems to take advantage of the phrase,
"Any outstanding asynchronous I/O operations may be cancelled" and
closes the ttys by flushing the pending input/output and
merrily quits the process and the shell prompt appears immediately.
Again, there doesn't seem to be any preference one way or the other.
For my taste though, quiting the process with extreme prejudice
might be preferable. YMMV.
Happy Hacking,
Chiaki Ishikawa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:23 EST