Re: [MinGW-dvlpr] Please vote: should we fix or drop the usleep() function?

[Keith M. <kei...@us...>]

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.