[fpc-pascal]Signals revisited
md
md at realmwireless.com
Thu Nov 2 22:53:53 CET 2000
Michael:
I am still trying to get a grip on signals:
There are three classes of signals as I know them to be:
Fatal Signals involving core dump
Mild Signals requesting application supported shutdown
Who cares Signals - Ignore them, they do not apply
The fatal signals include:
SIGSEGV, SIGFPE, SIGILL, and SIGTRAP.
The mild signals include:
SIGINT
SIGQUIT
SIGABRT
SIGBUS
SIGSEGV
SIGTERM
SIGPWR
Who cares signals include:
SIGHUP
SIGUSR1
SIGUSR2
SIGPIPE
SIGALRM
SIGSTKFLT
SIGCHLD
SIGCONT
SIGTSTP
SIGTTIN
SIGTTOU
SIGURG
SIGXCPU
SIGXFSZ
SIGVTALRM
SIGPROF
SIGWINCH
SIGIO
The Fatal signals I just don't even handle.
The Mild signals I install a handler for them, but I do not raise the
signal again after handling the signal.
I am assuming the behavior of the system after the handler not raising(
) another signal
is to proceed as normal.
Or should I try to do shutdown activities within the context of the
signal handler?
Again, it is the implementation in handling these signals without
causing exception violations is the key.
What happens to the executing context of the process when a signal is
raised. Does that process go idle in the kernel while he handler
executes?
Your response appreciated.
Mark Diener
Michael.VanCanneyt at wisa.be wrote:
>
> On Wed, 1 Nov 2000, md wrote:
>
> > I guess you are in Belgium somewhere. Maybe Brussels?
>
> About 25 Km. east of Brussels, to be exact.
>
> >
> > This signal stuff is excellent white paper material.
>
> Indeed.
>
> >
> > Some "mysteries of signals" lifted.
> >
> > >From your response, I am assuming that I cannot reinstall the handler
> > while inside the handler.
>
> No, you can, and most signal handlers do this as the first thing, to be
> able to trap the error if it should occur again.
>
> >
> > To continue default behavior, I must raise( ) the signal again and
> > default core dumping
> > and terminating will take place.
>
> yes. Only you should use sigraise(), not raise()
>
> >
> > Only for the stop signal must I raise an SIGCONT signal.
>
> If you want to continue execution, yes.
>
> >
> > >From what I conclude, I can handle the signal then Raise it again and
> > the default processing
> > would take place. If I do not raise it again, the default processing
> > will not take place.
>
> Correct.
>
> >
> > Please confirm these statements.
>
> Request fulfilled, I hope...
>
> Michael.
> >
> > Mark Diener
> >
> > Michael.VanCanneyt at wisa.be wrote:
> > >
> > > On Wed, 1 Nov 2000, md wrote:
> > >
> > > > Please ignore my earlier posting on signals.
> > > >
> > > > I have found an explanation of many signals at the following web
> > > > address:
> > > >
> > > > http://step.polymtl.ca/~ldd/syscalls/syscalls_99.html
> > >
> > > I will add this list to the documentation, as it may be useful.
> > >
> > > >
> > > > Notice on the web page it refers to
> > > > "terminates" and "stops" in parentheses.
> > > > What do you think that means?
> > >
> > > It refers to the behaviour if the signal is not caught. i.e. if the signal
> > > SIGHUP is not caught, the program will be terminated.
> > >
> > > >
> > > > Are there signal handlers that actually freeze the process and how do we
> > > > override this
> > > > behavior if it is true. Every process should keep executing regardless
> > > > of signal handled.
> > >
> > > The KILL signal will terminate the process. There is no way to stop this,
> > > as this signal cannot be caught.
> > >
> > > The STOP signal will freeze the process till it gets a 'CONTINUE' signal.
> > > This cannot be stopped either, AFAIK.
> > >
> > > All other signals can be caught and should be caught if they can appear in
> > > your program.
> > >
> > > >
> > > > What is still unclear is how to have a signal handle perform internal
> > > > processing
> > > > and still allow for system default core dumping and process termination.
> > >
> > > By default, the signal handler is uninstalled when it is called. You can
> > > 1) Not reinstall it in the handler.
> > > 2) send the same signal again to yourself.
> > > (both steps must be done)
> > >
> > > then you'll get the default behaviour. This should only be done for signals
> > > that can generate a core dump.
> > >
> > > Michael.
> > > >
> > > > The core dump is helpful for debugging purposes.
> > > >
> > > > Any help appreciated,
> > > >
> > > > Mark
> > > >
> > > >
> > > > Michael.VanCanneyt at wisa.be wrote:
> > > > >
> > > > > On Tue, 31 Oct 2000, md wrote:
> > > > >
> > > > > > FPC developers:
> > > > > >
> > > > > > Here is a brain teaser.
> > > > > >
> > > > > > Let us say we have two environments:
> > > > > >
> > > > > > 1) Normal BASH shell with prompt in TTY1 - The TERM environment
> > > > > > variable will be set to linux
> > > > > > 2) KDE Destktop - The TERM environment variable will be set to xterm
> > > > > >
> > > > > > Under the non-x window environment, how do we fork() / execlp( ) another
> > > > > > process so that the new child process
> > > > > > will use a different Ttty console to output its writeln( ) information
> > > > > > to.
> > > > > >
> > > > > > Under KDE, I can execute a fork() with execlp( ) and the command line
> > > > > > will be as follows 'konsole -e /bin/application arg1'
> > > > > >
> > > > > > The net effect of this is that the parent process continues in its own
> > > > > > console window and the child process will execute
> > > > > > in a separte console window. The input/output of each process is now
> > > > > > separate to each window.
> > > > > >
> > > > > > Under non-xwindows environments, .i.e. normal bash shell, How do we
> > > > > > fork() / exec( ) a process so that it will be assigned a different TTY
> > > > > > or some other means of having a separate console for each process.
> > > > >
> > > > > under bash, one would type:
> > > > >
> > > > > command args >/dev/ttyX 2>&1 </dev/ttyX &
> > > > >
> > > > > or under csh
> > > > >
> > > > > command args >& /dev/ttyX </dev/ttyX
> > > > >
> > > > > (replace X with the terminal number)
> > > > >
> > > > > The /dev/ files need the correct permissions, of course.
> > > > >
> > > > > under FPC you would do the following;
> > > > >
> > > > > fork
> > > > > if pid=0 then
> > > > > // Child
> > > > > begin
> > > > > // Same effect as below may be gotten with dup2() !!
> > > > > Close(input);
> > > > > Close(output);
> > > > > Close(stderr);
> > > > > Assign(Input,'/dev/ttyx');
> > > > > Assign(output,'/dev/ttyx');
> > > > > Assign(stderr,'/dev/ttyz');
> > > > > Reset(input);
> > > > > Rewrite(output);
> > > > > Rewrite(stderr);
> > > > > Execlp('command','args')
> > > > > end
> > > > > else
> > > > > begin
> > > > > // Parent
> > > > >
> > > > > end;
> > > > >
> > > > > >
> > > > > > What this also means that the login process for a given TTY is skipped
> > > > > > or avoided so the processes that are started from
> > > > > > the runlevel 3 inittab file can spawn processes that will take over a
> > > > > > given console.
> > > > >
> > > > > You'd better do that, yes.
> > > > >
> > > > > >
> > > > > > This is different that just logging into a bunch of different consoles
> > > > > > and running each process on a given console. This is where the code is
> > > > > > assigning processes to consoles.
> > > > > >
> > > > > > Any help would be appreciated.
> > > > >
> > > > > I hope the above helps.
> > > > >
> > > > > Michael.
> > > > >
> > > > > _______________________________________________
> > > > > fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> > > > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> > > >
> > > > _______________________________________________
> > > > fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> > > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> > > >
> > >
> > > _______________________________________________
> > > fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> >
> > _______________________________________________
> > fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> >
>
> _______________________________________________
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
More information about the fpc-pascal
mailing list