[fpc-pascal]Signals revisited

[Michael.VanCanneyt at Wisa.be]

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
>