View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001087 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2016-10-14 05:07 | 2024-06-11 09:09 |
| Reporter | philip-guenther | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted | ||
| Name | Philip Guenther | ||||
| Organization | OpenBSD | ||||
| User Reference | |||||
| Section | truncate | ||||
| Page Number | 2178 | ||||
| Line Number | 69754 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0001087: truncate() should behave like write() and generate SIGXFSZ for the thread instead of the process | ||||
| Description | Lines 69753-69754 say: If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the process. This is inconsistent with the requirement on write(): If the request would cause the file size to exceed the soft file size limit for the process and there is no room for any bytes to be written, the request shall fail and the implementation shall generate the SIGXFSZ signal for the thread. As well as XSH section 2.4.1: Signals which are generated by some action attributable to a particular thread, such as a hardware fault, shall be generated for the thread that caused the signal to be generated. | ||||
| Desired Action | Change lines 69753-69754 from: If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the process. to: If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the thread. | ||||
| Tags | tc3-2008 | ||||
|
|
I agree this appears to be an oversight from when <pthread.h> first appeared, but I'd expect the desired change to break existing implementations and applications that rely on them. They will be queuing the signal to the initial thread of the process (what was the only thread), reading that strictly, not to a thread it initiates with pthread_create() that might be making the call that fails. If the signal gets queued directly to the thread calling the interface with this change that thread would need code added to set its sigmask to accept the signal, and possibly register a handler specific to the thread with sigaction(), that it didn't need before. Something like a pthread_truncate(same params) might be better as providing that functionality, as an XSI addition specific to truncate(), or some other method of indicating that is the behavior the application wants. For a generic capability, adding SA_THREADFIRST as a sigaction flags option, with the behavior that a particular signal shall be queued to the main thread of a process only if a thread has the signal blocked or set to SIG_IGN, is another possibility. The main thread could set a signal handler for handling forwarded signals, or signals specified to be queued to it, and each thread calling truncate() could install a handler with that flag set to get thread specific handling. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-10-14 05:07 | philip-guenther | New Issue | |
| 2016-10-14 05:07 | philip-guenther | Name | => Philip Guenther |
| 2016-10-14 05:07 | philip-guenther | Organization | => OpenBSD |
| 2016-10-14 05:07 | philip-guenther | Section | => truncate |
| 2016-10-14 05:07 | philip-guenther | Page Number | => 2178 |
| 2016-10-14 05:07 | philip-guenther | Line Number | => 69754 |
| 2016-10-14 07:48 | shware_systems | Note Added: 0003414 | |
| 2018-04-12 17:07 | shware_systems | Note Edited: 0003414 | |
| 2018-04-19 15:19 | geoffclare | Interp Status | => --- |
| 2018-04-19 15:19 | geoffclare | Status | New => Resolved |
| 2018-04-19 15:19 | geoffclare | Resolution | Open => Accepted |
| 2018-04-19 15:19 | geoffclare | Tag Attached: tc3-2008 | |
| 2019-10-28 10:46 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:09 | agadmin | Status | Applied => Closed |
