[1003.1(2016)/Issue7+TC2 0001143]: cancellation points: contradiction between base definition and rationale
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1143 == Reported By:dstaesse Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1143 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Dimitri Staessens Organization: User Reference: Section:2.9.5 Page Number:520 Line Number:18219-18223 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-14 13:59 UTC Last Modified: 2017-06-20 03:50 UTC == Summary:cancellation points: contradiction between base definition and rationale == -- (0003790) dstaesse (reporter) - 2017-06-20 03:50 http://austingroupbugs.net/view.php?id=1143#c3790 -- I interpret the "shall occur" list as functions that have to be cancellation points in every implementation, whereas the "may occur" list are function that may be cancellation points in some implementations but not in others. Portable code should take that into account. Whether cancellation should have precedence over returning any "shall fail" case (or a success case for that matter) is of course a choice (they can't both happen). The old rationale you quote allows the function not to perform the cancellation check if it would not block indefinitely. That seems to have been changed in newer versions so that cancellation has precedence always at some point (which, to me, is the case that leads to the most robust specification). The current text seems to allow undefined behaviour for some cases (functions that timeout) but not others (and has the above contradiction). This undefined behaviour based on an input parameter that cannot be fixed is the case to avoid. As an example, a 1 microsecond timeout may never be an expired value on a fast machine where the code is running on a dedicated core, sometimes be expired on an equally fast machine that schedules different processes, and always be expired on a very slow machine. This is hardly a portable interface, as program behaviour may become unpredictable. Not all cancellation points with a timeout return ETIMEDOUT that allows easy implementation of a check. Why would any thread that 1) has a defined cancellation point in the code and 2) has a pending cancellation (so the program expects that thread to exit as soon as possible) and 3) was not yet executing that cancellation point and suspended when the cancellation request arrived be allowed to continue existing until some timeout expires, or be allowed to postpone that cancellation indefinitely unless another cancellation point is explicitly added to explicitly (a pthread_testcancel()) avoid such a case? Doesn't it make more sense to make cancellation mandatory for the above case, and only allow undefined behaviour if (and only if) clause 3) above is not met? That allows avoiding complexity in the implementation of the cancellation point so that it doesn't have to perform the cancellation check at awkward points in the code and roll back state and release already allocated resources? At least that's how I see the intention of the current version of the base specification. Issue History Date ModifiedUsername FieldChange == 2017-06-14 13:59 dstaesse New Issue 2017-06-14 13:59 dstaesse Name => Dimitri Staessens 2017-06-14 13:59 dstaesse Section => 2.9.5 2017-06-14 13:59 dstaesse Page Number => 520 2017-06-14 13:59 dstaesse Line Number => 18219-18223 2017-06-14 14:25 terekhov Note Added: 0003760 2017-06-15 18:49 dstaesse Note Added: 0003765 2017-06-17 12:17 dstaesse Note Added: 0003783 2017-06-19 09:04 terekhov Note Added: 0003784 2017-06-20 03:50 dstaesse Note Added: 0003790 =
[1003.1(2016)/Issue7+TC2 0001151]: Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1151 == Reported By:Clausecker Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1151 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Robert Clausecker Organization: Fraunhofer Fokus User Reference: Section:termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize Page Number:414, 333, 494, 212 Line Number:13877, 5, 16845–16879, 7040 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-19 16:41 UTC Last Modified: 2017-06-19 18:43 UTC == Summary:Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size == -- (0003789) Clausecker (reporter) - 2017-06-19 18:43 http://austingroupbugs.net/view.php?id=1151#c3789 -- struct winsize is the historic name for this structure, used since at least 1989. Renaming it might cause more problems than it solves. Note that tcsetsize and tcgetsize aren't reserved by POSIX either (probably by mistake). Mandating unsigned long as the type for the members is a bad idea as this contradicts existing implementations. All implementations I checked use unsigned short for this type. As I already mentioned, introducing a typedef windim_t might be a good compromise between compatibility and future expansions. I don't see how adding ENOTSUP might be a good idea. If the terminal's size cannot be changed, an implementation may either decide to make size changes have no effect (this might be a good idea for serial ports where the device driver cannot change the terminal but e.g. login(8) might want to set up the window size with information from the termcap database) or decide that each other possible terminal size is invalid, returning EINVAL. Changing the terminal size to itself should never cause an error, even on a fixed-size terminal. Perhaps that invariant should be specified, too. Issue History Date ModifiedUsername FieldChange == 2017-06-19 16:41 Clausecker New Issue 2017-06-19 16:41 Clausecker File Added: sigwinch-proposal.txt 2017-06-19 16:41 Clausecker Name => Robert Clausecker 2017-06-19 16:41 Clausecker Organization => Fraunhofer Fokus 2017-06-19 16:41 Clausecker Section => termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize 2017-06-19 16:41 Clausecker Page Number => 414, 333, 494, 212 2017-06-19 16:41 Clausecker Line Number => 13877, 5, 16845–16879, 7040 2017-06-19 17:32 shware_systems Note Added: 0003786 2017-06-19 17:33 shware_systems Note Edited: 0003786 2017-06-19 18:06 EdSchouten Note Added: 0003787 2017-06-19 18:11 shware_systems Note Added: 0003788 2017-06-19 18:43 Clausecker Note Added: 0003789 ==
[1003.1(2016)/Issue7+TC2 0001151]: Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1151 == Reported By:Clausecker Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1151 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Robert Clausecker Organization: Fraunhofer Fokus User Reference: Section:termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize Page Number:414, 333, 494, 212 Line Number:13877, 5, 16845–16879, 7040 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-19 16:41 UTC Last Modified: 2017-06-19 18:11 UTC == Summary:Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size == -- (0003788) shware_systems (reporter) - 2017-06-19 18:11 http://austingroupbugs.net/view.php?id=1151#c3788 -- Because other applications may use winsize for other purposes, as struct tag or other context. Issue History Date ModifiedUsername FieldChange == 2017-06-19 16:41 Clausecker New Issue 2017-06-19 16:41 Clausecker File Added: sigwinch-proposal.txt 2017-06-19 16:41 Clausecker Name => Robert Clausecker 2017-06-19 16:41 Clausecker Organization => Fraunhofer Fokus 2017-06-19 16:41 Clausecker Section => termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize 2017-06-19 16:41 Clausecker Page Number => 414, 333, 494, 212 2017-06-19 16:41 Clausecker Line Number => 13877, 5, 16845–16879, 7040 2017-06-19 17:32 shware_systems Note Added: 0003786 2017-06-19 17:33 shware_systems Note Edited: 0003786 2017-06-19 18:06 EdSchouten Note Added: 0003787 2017-06-19 18:11 shware_systems Note Added: 0003788 ==
[1003.1(2016)/Issue7+TC2 0001151]: Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1151 == Reported By:Clausecker Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1151 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Robert Clausecker Organization: Fraunhofer Fokus User Reference: Section:termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize Page Number:414, 333, 494, 212 Line Number:13877, 5, 16845–16879, 7040 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-19 16:41 UTC Last Modified: 2017-06-19 18:06 UTC == Summary:Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size == -- (0003787) EdSchouten (reporter) - 2017-06-19 18:06 http://austingroupbugs.net/view.php?id=1151#c3787 -- Why call it winsize_t, as opposed to 'struct winsize', which is the current convention? Issue History Date ModifiedUsername FieldChange == 2017-06-19 16:41 Clausecker New Issue 2017-06-19 16:41 Clausecker File Added: sigwinch-proposal.txt 2017-06-19 16:41 Clausecker Name => Robert Clausecker 2017-06-19 16:41 Clausecker Organization => Fraunhofer Fokus 2017-06-19 16:41 Clausecker Section => termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize 2017-06-19 16:41 Clausecker Page Number => 414, 333, 494, 212 2017-06-19 16:41 Clausecker Line Number => 13877, 5, 16845–16879, 7040 2017-06-19 17:32 shware_systems Note Added: 0003786 2017-06-19 17:33 shware_systems Note Edited: 0003786 2017-06-19 18:06 EdSchouten Note Added: 0003787 ==
[1003.1(2016)/Issue7+TC2 0001151]: Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1151 == Reported By:Clausecker Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1151 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Robert Clausecker Organization: Fraunhofer Fokus User Reference: Section:termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize Page Number:414, 333, 494, 212 Line Number:13877, 5, 16845–16879, 7040 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-19 16:41 UTC Last Modified: 2017-06-19 17:32 UTC == Summary:Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size == -- (0003786) shware_systems (reporter) - 2017-06-19 17:32 http://austingroupbugs.net/view.php?id=1151#c3786 -- Extensions to termios.h === A new subsection named "The winsize_t structure" is added to the header termios.h right after the section "The termios structure." The type "unsigned short" follows historical convention. Perhaps the committee wishes to instead introduce appropriate integer types for the structure members instead. This might be useful for implementations aiming to support terminals with more than 65535 horizontal or vertical pixels. The winsize_t Structure - The header shall define the winsize_t structure, which shall include at least the following members: unsigned long ws_row rows, in characters. unsigned long ws_col columns, in characters. [XSI] or [UP] unsigned long ws_xpixel horizontal size, in pixels, if supported. unsigned long ws_ypixel vertical size, in pixels, if supported. [x] In all members named in this volume of POSIX.1 2008, a value of 0 shall indicate that the value is unknown. === Additional edits after as winsize an app reserved identifier, *_t standard reserved. Use of termios as a type identifier a grandfathered allowance. Changed to long as display arrays can have now over 65k chars or pixels easily enough with UHD 4k resolutions, yet be logically a single terminal. Option group added as base POSIX will still only require support for char array or line oriented devices, not pixel or vector based. This was part of Bug 1053 discussion. Moving any added support for vectors or pixels to the base is an Issue 9 matter. Errors for tcsetsize() is missing ENOSUP as a 'may fail' entry, also discussed, for terminals that have fixed dimensions. Believe additional text related to LINES and COLUMNS env. variables also desirable. Issue History Date ModifiedUsername FieldChange == 2017-06-19 16:41 Clausecker New Issue 2017-06-19 16:41 Clausecker File Added: sigwinch-proposal.txt 2017-06-19 16:41 Clausecker Name => Robert Clausecker 2017-06-19 16:41 Clausecker Organization => Fraunhofer Fokus 2017-06-19 16:41 Clausecker Section => termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize 2017-06-19 16:41 Clausecker Page Number => 414, 333, 494, 212 2017-06-19 16:41 Clausecker Line Number => 13877, 5, 16845–16879, 7040 2017-06-19 17:32 shware_systems Note Added: 0003786 ==
[1003.1(2016)/Issue7+TC2 0001151]: Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1151 == Reported By:Clausecker Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1151 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Robert Clausecker Organization: Fraunhofer Fokus User Reference: Section:termios.h, signal.h, 2.4.3 "Signal Actions", 11.2 "Parameters that Can be Set", new sections tcgetsize and tcsetsize Page Number:414, 333, 494, 212 Line Number:13877, 5, 16845–16879, 7040 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-19 16:41 UTC Last Modified: 2017-06-19 16:41 UTC == Summary:Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size Description: This proposal aims to standardize the broadly available signal SIGWINCH and an extension to termios to query and set the terminal window size. This extension is designed to be easily implementable in terms of the TIOCGWINSZ and TIOCSWINSZ ioctl() calls available on many UNIX-like systems. This proposal does not contain an extension to the stty utility as that is already considered in the scope of [bug 1053]. This proposal introduces new functions tcgetsize() and tcsetsize() instead of introducing the ioctl() calls TIOCGWINSZ and TIOCSWINSZ as POSIX generally does not standardize the ioctl() except for the STREAMS interface. The desired action is rather large and posted both inline and as an attachment to the bug report in case the bug tracker garbles it. [bug 1053]: http://austingroupbugs.net/view.php?id=1053 Desired Action: Extensions to termios.h === A new subsection named "The winsize structure" is added to the header termios.h right after the section "The termios structure." The type "unsigned short" follows historical convention. Perhaps the comittee wishes to instead introduce appropriate integer types for the structure members instead. This might be useful for implementations aiming to support terminals with more than 65535 horizontal or vertical pixels. The winsize Structure - The header shall define the winsize structure, which shall include at least the following members: unsigned short ws_row rows, in characters. unsigned short ws_col columns, in characters. unsigned short ws_xpixel horizontal size, in pixels. unsigned short ws_ypixel vertical size, in pixels. In all members named in this volume of POSIX.1 2008, a value of 0 shall indicate that the value is unknown. Furthermore, the list of declared functions shall be amended with the following two entries: int tcgetsize(int, struct winsize *); int tcsetsize(int, const struct winsize *); The section "CHANGE HISTORY" shall be amended appropriately. Extensions to signal.h == The table of signals shall be amended with the following entry: Signal: SIGWINCH Default Action: I Description:Window size changed. The entry shall be added immediately after the entry for SIGUSR1. The section "CHANGE HISTORY" shall be amended appropriately. Extensions to §2.4.3 Signal Actions === The list of async-signal-safe functions shall be amended by the functions tcgetsize() and tcsetsize(). New function "tcgetsize" A new page "tcgetsize" shall be added to the list of system interfaces. Its text is analogous to that of tcgetattr and shall be as follows: NAME tcgetsize -- get the window size associated with a terminal SYNOPSIS #include int tcgetsize(int fildes, struct winsize *winsize_p); DESCRIPTION The tcgetsize() function shall get the window size associated with the terminal referred to by fildes and store them in the winsize structure pointed to by winsize_p. The fildes argument is an open file descriptor associated with a terminal. The winsize_p argument is a pointer to a winsize structure. It is implementation defined whether the window size associated with a terminal refers to the actual size and resolution of the terminal connected to the communication port asso
[1003.1(2016)/Issue7+TC2 0001121]: is the stat data undefined for dangling symlinks, without FTW_PHYS?
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1121
==
Reported By:djdelorie
Assigned To:ajosey
==
Project:1003.1(2016)/Issue7+TC2
Issue ID: 1121
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: Under Review
Name: DJ Delorie
Organization: Red Hat Inc
User Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1422736
Section:nftw()
Page Number:http://pubs.opengroup.org/onlinepubs/9699919799/
Line Number:n/a
Interp Status: ---
Final Accepted Text:
==
Date Submitted: 2017-02-24 18:47 UTC
Last Modified: 2017-06-19 12:54 UTC
==
Summary:is the stat data undefined for dangling symlinks,
without FTW_PHYS?
==
--
(0003785) mtk (reporter) - 2017-06-19 12:54
http://austingroupbugs.net/view.php?id=1121#c3785
--
So, I dug deeper on this issue, and discovered that the Linux/glibc
implementation used to the same thing as every other implementation.
See https://bugzilla.redhat.com/show_bug.cgi?id=1422736#c11
Until glibc 2.3.6, in the io/ftw.c process_entry() code, we find:
if (((data->flags & FTW_PHYS)
? LXSTAT (_STAT_VER, name, &st)
: XSTAT (_STAT_VER, name, &st)) < 0)
{
if (errno != EACCES && errno != ENOENT)
result = -1;
else if (!(data->flags & FTW_PHYS)
&& LXSTAT (_STAT_VER, name, &st) == 0
&& S_ISLNK (st.st_mode))
flag = FTW_SLN;
else
flag = FTW_NS;
}
So, if FTW_PHYS was not set, use stat() on the path. If that fails (because
of a dangling symlink, for example), then try lstat() on the path and check
if the result is symlink; if so, emit FTW_SLN.
In glibc 2.4 (~2006) things changed to the situation we currently have. The
change *appears* to be an unintended regression, since the associated
changelog message make no mention of modifying the behavior of FTW_SLN.
So, I do think this is a glibc bug, not a fault in the standard, per se
(though the standard could be a little clearer).
Issue History
Date ModifiedUsername FieldChange
==
2017-02-24 18:47 djdelorie New Issue
2017-02-24 18:47 djdelorie Status New => Under Review
2017-02-24 18:47 djdelorie Assigned To => ajosey
2017-02-24 18:47 djdelorie Name => DJ Delorie
2017-02-24 18:47 djdelorie Organization => Red Hat Inc
2017-02-24 18:47 djdelorie User Reference=>
https://bugzilla.redhat.com/show_bug.cgi?id=1422736
2017-02-24 18:47 djdelorie Section => nftw()
2017-02-24 18:47 djdelorie Page Number =>
http://pubs.opengroup.org/onlinepubs/9699919799/
2017-02-24 18:47 djdelorie Line Number => n/a
2017-02-24 20:38 shware_systems Note Added: 0003570
2017-02-25 03:06 carlos Note Added: 0003571
2017-02-26 19:59 mtkNote Added: 0003574
2017-02-27 09:50 geoffclare Project 1003.1(2008)/Issue 7 =>
1003.1(2016)/Issue7+TC2
2017-04-26 17:06 djdelorie Note Added: 0003675
2017-04-27 10:34 shware_systems Note Added: 0003676
2017-04-27 10:39 joerg Note Added: 0003677
2017-04-27 10:40 joerg Note Edited: 0003677
2017-06-19 12:54 mtkNote Added: 0003785
==
Re: Quick timey question.
Robert Elz wrote: > If yu can deal with timespec's instead of timeval's (and you really should) > you can easily > > #define gettimeofday(t, trash) glock_gettime(CLOCK_REALTIME, (t)) > > and barely notice the difference. If you need timevals, it is not hard > to convert. if you need timevals, use gettimeofday(). Note that gettimeofday() is much faster than glock_gettime(CLOCK_REALTIME, tp) on Solaris as gettimeofday() uses a fasttrap kernel interface. BTW: On Solaris, you could use: clock_gettime(__CLOCK_REALTIME0, tp), to get a fasttrap as well. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
[1003.1(2016)/Issue7+TC2 0001143]: cancellation points: contradiction between base definition and rationale
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1143 == Reported By:dstaesse Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1143 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Dimitri Staessens Organization: User Reference: Section:2.9.5 Page Number:520 Line Number:18219-18223 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-14 13:59 UTC Last Modified: 2017-06-19 09:04 UTC == Summary:cancellation points: contradiction between base definition and rationale == -- (0003784) terekhov (reporter) - 2017-06-19 09:04 http://austingroupbugs.net/view.php?id=1143#c3784 -- Reverting ERN 27 won't undo normative mandatory "shall fail" detection of prior timeout. The "shall occur" regarding cancel is concerned with non failure mode (the case of no prior timeout... other 'failure modes' aside for a moment). Consider that in the past, the Rationale said: "Cancellation points are points inside of certain functions where a thread has to act on any pending cancellation request when cancelability is enabled, if the function would block. As with checking for signals, operations need only check for pending cancellation requests when the operation is about to block indefinitely." It is my understanding that shall "shall occur" list is meant to preclude "block indefinitely." Where as "may also occur" list is meant for functions with internal fast path with no danger to "block indefinitely" on that fast path (and with cancel delivery on slow path only). Issue History Date ModifiedUsername FieldChange == 2017-06-14 13:59 dstaesse New Issue 2017-06-14 13:59 dstaesse Name => Dimitri Staessens 2017-06-14 13:59 dstaesse Section => 2.9.5 2017-06-14 13:59 dstaesse Page Number => 520 2017-06-14 13:59 dstaesse Line Number => 18219-18223 2017-06-14 14:25 terekhov Note Added: 0003760 2017-06-15 18:49 dstaesse Note Added: 0003765 2017-06-17 12:17 dstaesse Note Added: 0003783 2017-06-19 09:04 terekhov Note Added: 0003784 ==
