Re: Please vote: should we fix or drop the usleep() function?
Keith Marshall <[email protected]> Tue, 23 Dec 2014 22:26:57 +0000
| Newsgroups | gmane.comp.gnu.mingw.devel |
|---|---|
| Organization | MinGW Project |
| Message-ID | <[email protected]> |
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. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net