Proposal for new ISO C 9x time API

Clive D.W. Feather clive at on-the-train.demon.co.uk
Thu Oct 8 19:25:46 UTC 1998


In message <3614D4DE.A60B452E at renault.fr>, Antoine Leca
<Antoine.Leca at renault.fr> writes
>> > - about xtime_delay, it should have some ways for this function
>> > to be not supported by implementations.
[...]
>My real concern is that lazy implementers (there are a lot of
>them) may, and probably will, implement it as a busy wait
>on some platforms, while other resources may be perhaps
>available, but probably more difficult to use.
>That is what I did not like.
>Also, I do not like the sad effect: if xtime_delay *could* be
>implemented as a busy wait, there will be some programmers
>that will refuse to use it for effiency reasons (look at
>the people that rewrite memmove because some implementers
>wrote it using malloc... thus avoiding the speedy block
>moves implemented by others :-( ).
>
>But you are right that a "delay" statement (in one way or
>another) is a practical quest for a fair number of people.

This is not the right standard for a delay function; that's a much more
OS-specific operation and belongs in an OS standard like POSIX.

Just the same as "kbhit()" doesn't belong in the C Standard.

-- 
Clive D.W. Feather   | Regulation Officer, LINX | Work: <clive at linx.org>
Tel: +44 1733 705000 | (on secondment from      | Home: <cdwf at i.am>
Fax: +44 1733 353929 |  Demon Internet)         | <http://i.am/davros>
Written on my laptop; please observe the Reply-To address



More information about the tz mailing list