signal

Specifies an action to take place when certain conditions are detected (signalled) while a program executes

Local Servers:nonblocking
Remote Servers:N/A
Classification:ANSI
Service:Thread

Syntax

  #include <signal.h>  
   
  void (*signal  (  
     int    sig,   
     void   (*func) (  
        int)))  
     (int); 
  

Parameters

sig
(IN) Specifies the condition being signalled.
func
(IN) Points to the function to be called when the signalled condition occurs.

Return Values

Returns the previous setting if successful or SIG_ERR if a failure occurred.

Remarks

signal is used to specify an action to take place when certain conditions are detected while a program executes. These conditions are defined to be:

Signal

Description

SIGABRT

Abnormal termination, caused by the abort function.

SIGFPE

An erroneous floating-point operation occurs, such as division by zero, overflow and underflow (supported only for compiler option / fpc; not supported for options /fpi, /7, /fpi87).

SIGILL

An illegal instruction is encountered. (Currently not supported.)

SIGINT

Raised if the Ctrl+C keys are pressed during screen output (other than to the System Console Screen).

SIGSEGV

An illegal memory reference is detected. (Currently not supported.)

SIGTERM

An UNLOAD command has been entered for the NL.

The func parameter is used to specify an action to take for the specified condition:

When the func parameter is a function name, that function is called equivalently to the following code sequence.

        /*"sig" is the condition being signalled*/  
     signal (sig, SIG_DFL);  
     (*func) (sig); 
  

The function specified by the func parameter can terminate the program by calling the exit, _exit, ExitThread, or abort functions. It can also call the longjmp function or it can return. Because the next signal is handled with default handling, the program must again call signal if it is desired to handle the next condition of the type that has been signalled.

NOTE:The exit, _exit, ExitThread, and abort functions cannot be called from the context of a SIGTERM handler or the server console will be inoperational.

A registered SIGTERM signal handler in NetWare 3.11, 4.x, 5.x, and 6.x is on a per-NLM basis.You only have to register your SIGTERM handler once for the NLM. The other signals are on a per-threadgroup basis. For these signals, you have to register your signal handler every time you start a new thread group (by calling the BeginThreadGroup function). If not, your signal handler is not called.

Setting

Description

SIG_IGN

This value causes the indicated condition to be ignored.

SIG_DFL

This value causes the default action for the condition to occur.

The initial settings for the NetWare API are as follows:

Signal

Default Setting

SIGABRT

SIG_DFL

SIGFPE

SIG_IGN

SIGILL

SIG_IGN

SIGINT

SIG_DFL

SIGSEGV

SIG_IGN

SIGTERM

SIG_DFL

A condition can be generated by a program by calling the raise function.

The default action for the SIGABRT action is to call _exit (3). The default action for SIGINT is to call abort (). The default action for the other conditions is to ignore the condition.

The functions registered with signal run as callbacks, so CLIB context is an issue. If a callback does not have CLIB context, it cannot make calls to the NetWare API functions that require context.

The functions registered for SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM have the thread group context of the thread that was running when the signal condition was detected. They can use the NetWare API functions without additional setup.

However, you do need to set up context for the functions registered for SIGABRT.

For 3.11 NLM applications, you must manually create the thread group context in your callback functions, by calling SetThreadGroupID and passing a valid thread group ID. Before this thread returns, it should reset its context to its original context, by setting the thread group ID back to its original value.

For 4.x, 5.x, and 6.x NLM applications, the context that is given to the callbacks when they are registered is determined by the value in the registering thread’s context specifier. You can set the context specifier to one of the following options:

  • NO_CONTEXT-Callbacks registered with this option are not given CLIB context. The advantage here is that you avoid the overhead needed for setting up CLIB context. The disadvantage is that without the context the callback is only able to call NetWare API functions that manipulate data or manage local semaphores.

    Once inside of your callback, you can manually give your callback thread CLIB context by calling SetThreadGroupID and passing in a valid thread group ID. If you manually set up your context, you need to reset its context to its original context, by setting the thread group ID back to its original value.

  • USE_CURRENT_CONTEXT-Callbacks registered with a thread that has its context specifier set to USE_CURRENT_CONTEXT have the thread group context of the registering thread.
  • A valid thread group ID-This is to be used when you want the callbacks to have a different thread group context than the thread that schedules them.

When a new thread is started with BeginThread, BeginThreadGroup or ScheduleWorkToDo, its context specifier is set to USE_CURRENT_CONTEXT by default.

You can determine the current setting of the registering thread’s context specifier by calling GetThreadContextSpecifier. You use SetThreadContextSpecifier to set the registering thread’s context specifier to one of the above options.

For more information on using CLIB context, see Context Problems with OS Threads.

See Also

abort, _exit, longjmp, raise, setjmp