Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signals #96

Closed
zwetan opened this issue Jun 1, 2017 · 2 comments
Closed

signals #96

zwetan opened this issue Jun 1, 2017 · 2 comments

Comments

@zwetan
Copy link
Member

zwetan commented Jun 1, 2017

we need to be able to manage those signals in a cross-platform way

SIGABRT - abort
SIGALRM - alarm
SIGHUP - Hangup
SIGINT - interrupt
SIGKILL - kill
SIGTERM - terminate

@zwetan
Copy link
Member Author

zwetan commented Jun 21, 2017

different set of problems

Under Windows signal()
support only a subset of signals

sig value Description
SIGABRT Abnormal termination
SIGFPE Floating-point error
SIGILL Illegal instruction
SIGINT CTRL+C signal
SIGSEGV Illegal storage access
SIGTERM Termination request

but wait ...

SIGINT is not supported for any Win32 application. When a CTRL+C interrupt occurs,
Win32 operating systems generate a new thread to specifically handle that interrupt.
This can cause a single-thread application, such as one in UNIX, to become
multithreaded and cause unexpected behavior.

so you want to use SetConsoleCtrlHandler to handle SIGINT

signal WIN32 keyboard char
SIGABRT SIGABRT
SIGALRM timeSetEvent
SIGINT CTRL_C_EVENT CTRL+C ^C
SIGBREAK CTRL_BREAK_EVENT CTRL+BREAK ?
SIGHUP CTRL_CLOSE_EVENT user close the console
CTRL_LOGOFF_EVENT user logoff
CTRL_SHUTDOWN_EVENT user shutdown the system
SIGTERM SIGTERM
SIGTSTP ??? CTRL+Z ^Z

also note from WinAPI WIN32HandlerRoutine

The system also displays the dialog box if the process does not respond
within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT,
and 20 seconds for CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT).

@zwetan
Copy link
Member Author

zwetan commented Jun 21, 2017

basic design is to handle the signals through the Program class
as it is a "special" class we can access from ShellCore.

for each signals we basically set a flag to true
then in the "main loop" we check the flag to raise the user assigned callback

example with SIGHUP

Program.onHangup( f:Function );

we store the callback function on the primordial thread
and then we call the native function

ProgramClass::_setHangupMonitor()

which then use the Platform.h interface

Platform::GetInstance()->setHangup(localHangupCallback, this);

A simple getter allow us to know if the flag is true or false

Program.hangedup

then in the "main loop" signalPending allow us to know if there are
one or more signals pending and call _handleSignals()
eg.

private function _handleSignals():void
{
    //SIGHUP
    if( Program.hangedup )
    {
        //...
        Program.runHangupCallback();
        //...
    }
}

if the callback does not exists, case where we pass a null
eg. Program.onHangup( null )

or if the "main loop" is not running

the signal will be caught but no actions happen
eg. a SIGHUP will not hangup the actual program

@zwetan zwetan added this to the 0.4.2 milestone May 21, 2018
@zwetan zwetan closed this as completed May 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant