From: Keith M. <kei...@us...> - 2014-11-20 16:41:16
|
Guys, Looking in ChangeLog, I see that (a broken) implementation of usleep() was added to mingwrt in 2008, just about the time that POSIX.1003-1 dropped it, and removed all references to it from the standard. So... 1) Should we go along with POSIX, and similarly drop it, or... 2) Retain it, but mark it as deprecated? I'm of two minds, but if we do decide on (2), then we should also fix the currently broken error return; those earlier versions of POSIX which did specify it said that it *may* fail if the requested delay is 1,000,000 microseconds or more, it which case it should set errno to EINVAL, and return -1; our implementation does not set errno, but returns EINVAL instead of -1. Furthermore, if we do vote to keep usleep(), it seems kind of anomalous that we don't also provide an implementation of sleep(), (which remains a mandatory POSIX function today). Thoughts? -- Regards, Keith. |
From: Yongwei Wu <wuy...@gm...> - 2014-11-21 06:56:00
|
Why breaking something already working (mostly)? I do not see Cygwin or Linux is dropping usleep. We could even leave it as it is, since it is no longer standard (though fixing something is always good, esp. if it is easy). I guess no one is actually checking the return value of usleep, anyway. My 2 cents. On 21 November 2014 00:41, Keith Marshall <kei...@us...> wrote: > Guys, > > Looking in ChangeLog, I see that (a broken) implementation of usleep() > was added to mingwrt in 2008, just about the time that POSIX.1003-1 > dropped it, and removed all references to it from the standard. So... > > 1) Should we go along with POSIX, and similarly drop it, or... > 2) Retain it, but mark it as deprecated? > > I'm of two minds, but if we do decide on (2), then we should also fix > the currently broken error return; those earlier versions of POSIX which > did specify it said that it *may* fail if the requested delay is > 1,000,000 microseconds or more, it which case it should set errno to > EINVAL, and return -1; our implementation does not set errno, but > returns EINVAL instead of -1. > > Furthermore, if we do vote to keep usleep(), it seems kind of anomalous > that we don't also provide an implementation of sleep(), (which remains > a mandatory POSIX function today). > > Thoughts? > > -- > Regards, > Keith. > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2014-11-22 16:30:31
|
On 21/11/14 06:55, Yongwei Wu wrote: > Why breaking something already working (mostly)? I do not see Cygwin > or Linux is dropping usleep. AIUI, Linux requires certain feature test macros to be specified, and Linux' glibc-2.12 (and later) *does* remove it, (or so the manpage implies), for applications which correctly specify _POSIX_C_SOURCE >= 200809L, or _XOPEN_SOURCE >= 700, (or which neglect to specify earlier versions of these, or alternative enabling macros[1]). [1] However, trivial testing would appear to refute this latter claim! The former *is* honoured, insofar as the prototype is removed from unistd.h, (resulting in a GCC warning), but the library implementation remains exposed for linking. > We could even leave it as it is, since it is no longer standard I'm not in favour of retaining *anything* in a broken state! However, *I* don't object to retaining it if it is fixed, although others here have objected, in the past, to including support for anything which is not MS standard, ISO-C standard, or (with some reluctance) POSIX, and since POSIX.1-2008, usleep() is none of these. > (though fixing something is always good, esp. if it is easy). It is trivially easy to fix ... just remove the faulty test altogether, since POSIX never *required* it to fail for the specified reason[2]. [2] FWIW, POSIX said it *may* (optionally) fail for a specified sleep interval in excess of 999,999 microseconds; Linux' glibc implementation *doesn't* impose this limitation. > I guess no one is actually checking the return value of usleep, anyway. I don't think I would go as far as to say that; perhaps no one is using it in a manner in which it fails ... which requires a specified sleep interval in excess of 999,999 microseconds. What we can say is that, those who are using it in failing manner either aren't checking for success, or are interpreting the failure mode improperly; either could be construed as an application bug. (I believe NetBSD may fail in this same circumstance, with the correct error return state). > My 2 cents. For which I'm grateful, since right now, no one else seems to be bothered enough to respond urgently. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2014-12-23 22:25:25
|
On 22/11/14 16:30, Keith Marshall wrote: > On 21/11/14 06:55, Yongwei Wu wrote: >> Why breaking something already working (mostly)? I do not see Cygwin >> or Linux is dropping usleep. > > [...snip...] > >> We could even leave it as it is, since it is no longer standard > > I'm not in favour of retaining *anything* in a broken state! However, > *I* don't object to retaining it if it is fixed, although others here > have objected, in the past, to including support for anything which is > not MS standard, ISO-C standard, or (with some reluctance) POSIX, and > since POSIX.1-2008, usleep() is none of these. > >> (though fixing something is always good, esp. if it is easy). > > It is trivially easy to fix ... just remove the faulty test altogether, > since POSIX never *required* it to fail for the specified reason[2]. FWIW, I've chosen an alternative resolution -- I've removed the current (broken) usleep.c, and replaced it with a more generic __mingw_sleep(), in nsleep.c: http://tinyurl.com/p2aa869 (committed on WSL/legacy), and I've then wrapped calls to this, in unistd.h, to provide __CRT_INLINE implementations of sleep(), usleep(), and nanosleep(). > [2] FWIW, POSIX said it *may* (optionally) fail for a specified sleep > interval in excess of 999,999 microseconds; Linux' glibc implementation > *doesn't* impose this limitation. Linux' glibc may choose this approach, but our implementation will continue to reject any excessively large interval. Furthermore, since usleep() had already been declared as obsolescent by the POSIX.1-2001 Issue 6 on which our original implementation was ostensibly based, and it has been completely removed from POSIX.1-2008 Issue 7, I've marked it with __MINGW_ATTRIB_DEPRECATED, so any reference to it, (or to its associated useconds_t data type), will trigger a GCC warning. -- Regards, Keith. |