{"push_id":2508402607,"size":1,"distinct_size":1,"ref":"refs/heads/signal_minimal_changes","head":"203030142b1fb54baa1c61d7bcec2103086d939f","before":"d9b22c9cfbff516d4cb9095d6b3b8d94fa58eded","commits":[{"sha":"203030142b1fb54baa1c61d7bcec2103086d939f","author":{"name":"Babneet Singh","email":"8abd1ff3f747df23e2285ffa6b8768f665774ab2@ca.ibm.com"},"message":"Extend OMR Signal API\n\n1) Added two new port library signal flags in omrport.h: SIGHUP and\nSIGCONT.\n\n2) Changed the signature of omrsig_set_single_async_signal_handler.\nBefore, it returned the address to the old OS handler. Address to the\nold OS handler can be NULL in non-error situations. So, it wasn't\npossible to distinguish between error and non-error scenarios. Now, it\nis changed to return 0 on success and non-zero on failure. The address\nof the old OS handler is returned via an input reference variable.\n\n3) Returning macro OMRPORT_SIG_ERROR (-1) from\nomrsig_map_portlib_signal_to_os_signal.\n\n4) Added Unix (port/unix/omrsignal.c) implementation of\nomrsig_set_single_async_signal_handler,\nomrsig_map_os_signal_to_portlib_signal and\nomrsig_map_portlib_signal_to_os_signal. Supporting trace points have\nbeen added in omrport.tdf.\n\n5) In Unix omrsignal.c, removed unused macro MAX_PORTLIB_SIGNAL_TYPES.\n\n6) Fix issue with re-registering master handlers. OMRSIG_SIGACTION can\nbe called outside of omrsignal.c functions. A call to OMRSIG_SIGACTION\nwill override the master handlers set by either omrsig_protect or\nomrsig_set_async_signal_handler. Setting a master handler once sets a\nbit in signalsWithMasterHandlers. If the master handler is overridden by\nan external call to OMRSIG_SIGACTION, then the bit in\nsignalsWithMasterHandlers will not be un-set. Since the bit in\nsignalsWithMasterHandlers isn't un-set once the master handler has been\noverridden, then subsequent calls to omrsig_protect and\nomrsig_set_async_signal_handler will not re-register the master handler.\nIn subsequent calls, it will look as if the master handler is already\nregistered. We mustn't rely on signalsWithMasterHandlers to re-register\nmaster handlers. It doesn't cause any harm to register master handlers\nevery time a call is made to either omrsig_protect or\nomrsig_set_async_signal_handler.\n\n7) Initialize oldAction before invoking OMRSIG_SIGACTION. Before\nregistering handlers using OMRSIG_SIGACTION, oldAction (struct\nsigaction) needs to be properly initialized or reset within\nregisterSignalHandlerWithOS.\n\n8) omrsig_set_single_async_signal_handler needs access to the old OS\nhandler. omrsig_set_single_async_signal_handler,\nomrsig_set_async_signal_handler and omrsig_protect call\nregisterMasterHandlers to register master handlers with the OS.\nregisterMasterHandlers calls registerSignalHandlerWithOS.\nregisterSignalHandlerWithOS has access to the old OS handler. The old OS\nhandler is returned via an input reference variable from\nregisterSignalHandlerWithOS to registerMasterHandlers, and then to any\ncaller of registerMasterHandlers. If the input reference variable is\nNULL, then the input reference variable is not updated. To allow this,\nthe definitions of registerMasterHandlers and\nregisterSignalHandlerWithOS has been updated.\n\n9) In Unix omrsignal.c, oldActions is used to cache the original OS\nhandler so that it can be restored during shutdown.\nregisterSignalHandlerWithOS registers a handler with the OS using\nOMRSIG_SIGACTION. While registering a handler with the OS, it gets\naccess to the old OS handler. Now, registerSignalHandlerWithOS can be\ncalled multiple times to register the master handlers (refer to point\n6). So, it should cache the old (original) OS handler in oldActions\nwhile registering the first handler. While registering subsequent\nhandlers, oldActions isn't updated.\n\n10) Added trace point in mapUnixSignalToPortLib to print error for\nunknown OS signal.\n\n11) MAX_UNIX_SIGNAL_TYPES corresponds to the total number of signals\navailable. All signals have a value greater than 0.\nMAX_UNIX_SIGNAL_TYPES should not be used to create an array for storing\ninformation related to signals. Instead, (MAX_UNIX_SIGNAL_TYPES + 1)\nshould be used to create an array for storing information related\nsignals. This will allow us to properly store the information for the\nMAX_UNIX_SIGNAL_TYPES(th) signal. Macro ARRAY_SIZE_SIGNALS has been\nadded to create arrays for storing information related to signals. \n\n12) In Unix omrsignal.c, signalMap has been updated to support three\nmore signals: SIGINT, SIGHUP and SIGCONT. All three are asynchronous\nsignals.\n\n13) Semaphores are no longer used to track counts for asynchronous\nsignals. Instead, an array (signalCounts) has been added to keep track\nof signal counts.\n\n14) masterASynchSignalHandler no longer updates semaphores to keep track\nof signal counts. Instead, it updates the signal specific array element\nwithin signalCounts via atomic operation. Then, it notifies the\nasynchSignalReporterThread.\n\n15) asynchSignalReporter has been modified. The code to invoke handlers\nhas been moved into another function named runHandlers.\nasynchSignalReporter no longer relies upon semaphores to determine which\nsignal should be handled. Instead, it checks the array elements of\nsignalCounts to determine the signal to be handled.\n\n16) The code to initialize and destroy unneeded semaphores has been\nremoved from initializeSignalTools and destroySignalTools.\n\nSigned-off-by: Babneet Singh <sbabneet@ca.ibm.com>","distinct":true,"url":"https://api.github.com/repos/babsingh/omr/commits/203030142b1fb54baa1c61d7bcec2103086d939f"}]}
{"actor":{"display_login":"babsingh"}}