[fpc-pascal]Signals revisited

[Michael.VanCanneyt at Wisa.be]

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
>