«

On Fri, 22 Feb 2008 20:16:58 -0500, CBFalconer wrote:

> mike3 wrote:
>>
>> Busy-waiting is a known anti-pattern that should be avoided. However,
>> in C, there is no standard alternative, so when a wait is required and
>> it's not busy, the program becomes 100% non-portable. So then why not
>> include this type of non-busy wait functionality in the standard?
>
> Sure, just as soon as you describe to us a sure-fire positive method of
> so doing on all the types of systems on which C runs. Note the word
> 'all'.

You have just eliminated the C standard library, at least significant
portions of it, as your "all" requirement there can't apply to them.
When will we be seeing the TC which eliminates all such functions from
the language?

Or maybe, just maybe, that "all" notion of yours is just a tired old red
herring?

Kenny McCormack wrote:
>
> In article <>,
> Kenneth Brody <> wrote:
> >mike3 wrote:
> >>
> >> Hi.
> >>
> >> Busy-waiting is a known anti-pattern that should be avoided. However,
> >> in C, there is no standard alternative, so when a wait is required
> >> and it's not busy, the program becomes 100% non-portable. So then why
> >> not include this type of non-busy wait functionality in the standard?
> >
> >What if the underlying platform has no such support? (eg: MS-DOS.)
> >
> >Not to mention, the concept of "non-busy waiting" implies a mutli-
> >tasking system.
>
> Anyone with couple of brain cells to rub together could see that the
> way to handle this is to allow the function to be a no-op if necessary.

One could say the same thing about functions to create a subdirectory,
open a socket, or draw a circle.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

In article <si9b95->,
Kelsey Bjarnason <> wrote:
>On Fri, 22 Feb 2008 20:16:58 -0500, CBFalconer wrote:
>
>> mike3 wrote:
>>>
>>> Busy-waiting is a known anti-pattern that should be avoided. However,
>>> in C, there is no standard alternative, so when a wait is required and
>>> it's not busy, the program becomes 100% non-portable. So then why not
>>> include this type of non-busy wait functionality in the standard?
>>
>> Sure, just as soon as you describe to us a sure-fire positive method of
>> so doing on all the types of systems on which C runs. Note the word
>> 'all'.
>
>You have just eliminated the C standard library, at least significant
>portions of it, as your "all" requirement there can't apply to them.
>When will we be seeing the TC which eliminates all such functions from
>the language?
>
>Or maybe, just maybe, that "all" notion of yours is just a tired old red
>herring?
>

CBF is just a tired old red herring.

In article <s18b95->,
Kelsey Bjarnason <> wrote:
>On Fri, 22 Feb 2008 17:18:51 -0500, Kenneth Brody wrote:
>
>> mike3 wrote:
>>>
>>> Hi.
>>>
>>> Busy-waiting is a known anti-pattern that should be avoided. However,
>>> in C, there is no standard alternative, so when a wait is required and
>>> it's not busy, the program becomes 100% non-portable. So then why not
>>> include this type of non-busy wait functionality in the standard?
>>
>> What if the underlying platform has no such support? (eg: MS-DOS.)
>
>Then it can just as readily be a busy loop. The whole point to a non-
>busy loop is to allow other processes to run; if there are no processes,
>a simple busy loop will suffice.
>

To be thoroughly, revoltingly pedantic (i.e., the norm for the group),
one should point out that if I were running MSDOS on a current laptop,
that laptop would have facilities to shut down (or slow down) the CPU to
save power and reduce wear (i.e., heat buildup) on the CPU. It can't do
this if the program busy-loops.

Kelsey Bjarnason wrote:
> CBFalconer wrote:
>> mike3 wrote:
>>>
>>> Busy-waiting is a known anti-pattern that should be avoided.
>>> However, in C, there is no standard alternative, so when a wait
>>> is required and it's not busy, the program becomes 100%
>>> non-portable. So then why not include this type of non-busy
>>> wait functionality in the standard?
>>
>> Sure, just as soon as you describe to us a sure-fire positive
>> method of so doing on all the types of systems on which C runs.
>> Note the word 'all'.
>
> You have just eliminated the C standard library, at least
> significant portions of it, as your "all" requirement there
> can't apply to them. When will we be seeing the TC which
> eliminates all such functions from the language?
>
> Or maybe, just maybe, that "all" notion of yours is just a
> tired old red herring?

Or, maybe, you should consider it as indicating the difficulty of
providing a portable generalized substitute for busy waiting?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:
>
> Or, maybe, you should consider it as indicating the difficulty of
> providing a portable generalized substitute for busy waiting?

I have to remind you that C++03 already offers such a facility, as I
posted in another message of mine.

Ioannis Vranos wrote:
> CBFalconer wrote:
>
>> Or, maybe, you should consider it as indicating the difficulty of
>> providing a portable generalized substitute for busy waiting?
>
> I have to remind you that C++03 already offers such a facility,
> as I posted in another message of mine.

C++ is a different languages, requiring different support, etc. We
can implement full C95 on a Z80, including all the minimum values.
By cutting those values we can implement C99 on the same machine
running standard CP/M. You can't do that with C++. That's one
reason why there is a separate newsgroup for it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

CBFalconer <> writes:
> Kelsey Bjarnason wrote:
>> CBFalconer wrote:
>>> mike3 wrote:
>>>> Busy-waiting is a known anti-pattern that should be avoided.
>>>> However, in C, there is no standard alternative, so when a wait
>>>> is required and it's not busy, the program becomes 100%
>>>> non-portable. So then why not include this type of non-busy
>>>> wait functionality in the standard?
>>>
>>> Sure, just as soon as you describe to us a sure-fire positive
>>> method of so doing on all the types of systems on which C runs.
>>> Note the word 'all'.
>>
>> You have just eliminated the C standard library, at least
>> significant portions of it, as your "all" requirement there
>> can't apply to them. When will we be seeing the TC which
>> eliminates all such functions from the language?
>>
>> Or maybe, just maybe, that "all" notion of yours is just a
>> tired old red herring?
>
> Or, maybe, you should consider it as indicating the difficulty of
> providing a portable generalized substitute for busy waiting?

Name one system with a hosted C implementation that doesn't have a
straightforward way of doing a non-busy wait. POSIX systems have
sleep(); other systems, I'm sure, have something similar.

If the sleep() function or something like it were required by the C
standard, I don't believe there would be any more difficulty in
implementing it than there has been in implementing the standard
time() function. There were other reasons, right or wrong, not to
include such a function in the standad.

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson said:

<snip>

> Name one system with a hosted C implementation that doesn't have a
> straightforward way of doing a non-busy wait.

MS-DOS (unless you count TSRs, which should almost certainly count as
cheating).

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:

> Keith Thompson said:
>
> <snip>
>
>> Name one system with a hosted C implementation that doesn't have a
>> straightforward way of doing a non-busy wait.
>
> MS-DOS (unless you count TSRs, which should almost certainly count as
> cheating).

<OT>

I think that there is nothing that potentially prevents a DOS system
from implementing a non-busy wait.

A call to sleep would invoke a system routine that would put the CPU to
sleep (using the HLT instruction), to be woken by the next clock
interrupt. The routine would of course examine the countdown timer and
keep calling HLT until the requested time period has elapsed.

</OT>