Please vote: should we fix or drop the usleep() function?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Please vote: should we fix or drop the usleep() function?

Keith Marshall-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Please vote: should we fix or drop the usleep() function?

Yongwei Wu
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
<[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr



--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Please vote: should we fix or drop the usleep() function?

Keith Marshall-3
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Please vote: should we fix or drop the usleep() function?

Keith Marshall-3
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...