![]() There is no ideal solution for portability of signals. At least with sigaction - you get the same functionality. If you need to be portable to most BSDs and *some* of the embedded POSIXy-kernels, but not ancient versions of any OS and only in systems with this POSIX RT extension (some systems don't support sigaction) - then sigaction is a better choice. signal() has been implemented as calls to sigaction() in glibc for years. The bottom line - if the plan is to get the job done and to be portable just across modern Linux distros there is nothing wrong with the current implementation of signal. After a series of incremental improvements the sigaction functionality was defined and is *reasonably* portable - but still has loose ends that need special ifdef's and attention. This made most signal handling incompatible - say between BSD Unices and Linux. The Original POSIX std defined 'signal()' but allowed several different semantics - the functionality operated differently on different systems. The man page SUGGESTS not using it except for a few special cases, and the justification by reciting part of the history fo this function and limits to it's portability. ![]() The function is not deprecate and is part of the POSIX.1-2001 standard. I think you and JP need to re-real the signal(2) man page again. You are just jamming data into things that appear to be similar to the documented API and the results are non-portable and unpredictable. Reason: correcting/expanding explaination.Ĭode: act._sigaction_handler.sa_handler=ouch you've gone away from the documented API. Last edited by jpollard 6th February 2012 at 08:30 AM. After that, the structure could be discarded, as it can be when the declaration is on the stack (as your example has, though it is in the main function). Saving this space is nearly pointless (pun deliberate ) as the sigaction structure is only used to initialize some kernel process parameters for use when invoking the signal handler. The code should work for either implementation of the sigaction structure. Using the sa_sigaction or sa_handler is therefore made portable. All the extra union does is to eliminate storage for an extra pointer (the flag SA_SIGINFO determines which will be used). That means that it works either way to say "act.sa_handler" or "act.sa_sigaction", but DON'T use both. ![]() This makes using _sigaction_handler.sa_handler OR _sigaction_handler.sa_sigaction superfluous as these are the same names when NOT using the "_USE_POSIX199309". } Note that when the "_USE_POSIX199309" is defined, the names "sa_handler" AND "sa_sigaction" are also both defined (the "#define. * Additional set of signals to be blocked. # define sa_sigaction _sigaction_handler.sa_sigaction # define sa_handler _sigaction_handler.sa_handler Void (*sa_sigaction) (int, siginfo_t *, void *) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |