Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001087 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2016-10-14 05:07 2019-10-28 10:46
Reporter philip-guenther View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
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
Attached Files

- Relationships

-  Notes
(0003414)
shware_systems (reporter)
2016-10-14 07:48
edited on: 2018-04-12 17:07

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.


- Issue History
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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker