a better way to busy wait?

[John Asmuth]

Is there a more friendly way to do this?

import "runtime"

//A not-so-busy wait
func WaitUntil(foo func() bool) {
for !foo() {
runtime.Gosched();
}
}

[smosher]

That is "better" but busywaiting at all is a sure sign that your
approach is all backwards.

[John Asmuth]

On Dec 9, 10:19 pm, smosher <dark.nowh...@gmail.com> wrote:

> That is "better" but busywaiting at all is a sure sign that your
> approach is all backwards.

It came up when I wanted to get a value from a channel, or know that
the channel got closed while I was waiting. Checking what comes out
for the zero value is not what I'm looking for. Select with a default
doesn't seem to do it either, though from the lang spec I'd think it
would.

Even more specifically, I was writing a concurrent Fold() function
(http://code.google.com/p/goconc/source/browse/fold.go) and I wanted
to try to read something from a channel (that I was treating like a
queue) until I either got something or knew that nothing else was
going to be pushed to the queue (another channel was closed).

[atomly]

Why not use another channel as a notification mechanism to mark completion?

--
:: atomly ::

[ ato...@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.917.442.9450 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[Devon H. O'Dell]

From IRC (for benefit of the list): what you want is to check
closed(). Relying on closed(c) returning true ensures you've read the
entire list, and guarantees that the last value you receive is the
zero value for the type over the chan (explained in the language spec
at http://golang.org/doc/go_spec.html#Close_and_closed)

--dho

[John Asmuth]

In this case, at least, I found a way around it. In general, I wonder
if a Trigger() function, that takes a indicator function and returns a
channel, sending a value on the channel the first time the indicator
is true, would be useful...

func Trigger(foo func() bool) chan bool {
response = make(chan bool);
go func() {
for !foo() {
runtime.Gosched();
}
response <- true;
}();
return response;
}

On Dec 9, 11:28 pm, inspector_jouve <kaushan...@gmail.com> wrote:
> But closed() is not the same as waitUntilClosed(). How to implement
> this other than by busy waiting?

[Russ Cox]

On Wed, Dec 9, 2009 at 22:03, John Asmuth <jas...@gmail.com> wrote:
> In this case, at least, I found a way around it. In general, I wonder
> if a Trigger() function, that takes a indicator function and returns a
> channel, sending a value on the channel the first time the indicator
> is true, would be useful...

This is not the way to think about things in Go.
The Go way is to make foo a func() with no
return value; calling it would block until the
channel should be written to. The even more
idiomatic Go way would be to make foo a
channel instead of a function:

func Trigger(req chan bool) chan bool {
c := make(chan bool)
go func() {
<-c
req <- true
}
return c
}

Any time you would use polling in a traditional
event-based system, think about using blocking
instead in Go.

Russ