View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000392 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2011-03-15 16:31 | 2013-04-16 13:06 |
| Reporter | geoffclare | Assigned To | ajosey | ||
| Priority | normal | Severity | Comment | Type | Omission |
| Status | Closed | Resolution | Accepted | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | sigtimedwait | ||||
| Page Number | 1952 | ||||
| Line Number | 62027 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000392: Give guidance on sigwaitinfo() and SA_SIGINFO | ||||
| Description | XSH section 2.4 says: When a signal is generated by the sigqueue() function or any signal-generating function that supports the specification of an application-defined value, the signal shall be marked pending and, if the SA_SIGINFO flag is set for that signal, the signal shall be queued to the process along with the application-specified signal value. This means that applications which use sigwaitinfo() or sigtimedwait() must set SA_SIGINFO for the signal(s) if they want generated signals to be queued and signal values to be available in si_value. There are some subtleties regarding how to set this up which it would be worth documenting in application usage. In particular, a dummy three-argument signal handling function is needed. | ||||
| Desired Action | Add a new paragraph to APPLICATION USAGE after line 62027: Note that in order to ensure generated signals are queued and signal values passed to sigqueue() are available in si_value, applications which use sigwaitinfo() or sigtimedwait() need to set the SA_SIGINFO flag for each signal in the set (see [xref to 2.4]). This means setting each signal to be handled by a three-argument signal catching function, even if the handler will never be called. It is not possible (portably) to set a signal handler to SIG_DFL while setting the SA_SIGINFO flag, because assigning to the sa_handler member of struct sigaction instead of the sa_sigaction member would result in undefined behavior, and SIG_DFL need not be assignment compatible with sa_sigaction. Even if an assignment of SIG_DFL to sa_sigaction is accepted by the compiler, the implementation need not treat this value as special - it could just be taken as the address of a signal catching function. | ||||
| Tags | tc1-2008 | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-03-15 16:31 | geoffclare | New Issue | |
| 2011-03-15 16:31 | geoffclare | Status | New => Under Review |
| 2011-03-15 16:31 | geoffclare | Assigned To | => ajosey |
| 2011-03-15 16:31 | geoffclare | Name | => Geoff Clare |
| 2011-03-15 16:31 | geoffclare | Organization | => The Open Group |
| 2011-03-15 16:31 | geoffclare | Section | => sigtimedwait |
| 2011-03-15 16:31 | geoffclare | Page Number | => 1952 |
| 2011-03-15 16:31 | geoffclare | Line Number | => 62027 |
| 2011-03-15 16:31 | geoffclare | Interp Status | => --- |
| 2011-05-05 16:23 | msbrown | Status | Under Review => Resolved |
| 2011-05-05 16:23 | msbrown | Resolution | Open => Accepted |
| 2011-05-05 16:23 | msbrown | Description Updated | |
| 2011-05-05 16:23 | msbrown | Desired Action Updated | |
| 2011-05-05 16:24 | Don Cragun | Tag Attached: tc1-2008 | |
| 2013-04-16 13:06 | ajosey | Status | Resolved => Closed |
