No subject

the default processing
would take place.  If I do not raise it again, the default processing
will not take place.

Please confirm these statements.

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