[go-nuts] channel communication - prevent main() exiting without Sleep() ?

[John]

Greetings all,

Is there any way to keep main() from exiting, say with this type of
skeleton scenario:

func main(){
var myChan chan int;
// ...
go sendSomething(myChan); //producer of data
go receiveSomething(myChan); //consumer of the data

}

func sendSomething(myChan chan int){

// create data, send on channel
}

func receiveSomething(myChan chan int){
//receive data, print out or otherwise utilize
}


-----------------------

I mean, I could put something like time.Sleep(5 * 1e9); in the main()
function at the end, but that seems kinda silly, especially if the
driver program may not know just how much data may be pumped and
received...

If you *don't* put a Sleep() though, my code exits immediately (which
makes sense, because main() executes independently of the send and
receive functions).

Any ideas?

Thanks,

John

[Rob 'Commander' Pike]

The idiom is
<-make(chan int)
which will hang forever.

But instead you could just not 'go' the last function. Call it directly.

-rob

[John]

Well, hanging forever isn't a good goal, but the second idea might
work. Let me try it out.

Also, why DOES code like:

for{
input = <- myChannel;
}

exit? It does break out of this loop... is that simply because it's
stopped receiving data or the channel went out of scope in the sending
method?

Thanks,

John

[roger peppe]

On 8 May 2010 04:49, John <gin...@gmail.com> wrote:
> Well, hanging forever isn't a good goal, but the second idea might
> work.  Let me try it out.
>
> Also, why DOES code like:
>
>   for{
>     input = <- myChannel;
>  }
>
> exit?  It does break out of this loop... is that simply because it's
> stopped receiving data or the channel went out of scope in the sending
> method?

it shouldn't exit. although it will exit if main returns, or
if someone calls os.Exit()

[Andrew Francis]

Hi:

I ran into this when I started to write Go programmes. I make main
wait on a channel. This may not help right now but some suggestions.

In Stackless, there is a method called stackless.getruncount() that
returns the number of
scheduled tasklets (coroutines)

So the main coroutine to have the following structure

set up the code
while getruncount() > 1:
schedule()

(in reality, a stackless programme uses stackless.run())

I notice in the runtime package, there is a function called Gosched()
that yields the processor.
It may not be difficult to put in a Gogetruncount()?

Based on stackless experience, an additional advantage I see is if the
programme deadlocks(i.e., due to cycle), the loop gracefully
terminates and one stands a fighting chance to run a deadlock
detector.

Cheers,
Andrew

[Russ Cox]

> I notice in the runtime package, there is a function called Gosched()
> that yields the processor.
> It may not be difficult to put in a Gogetruncount()?

This exposes far too much about the runtime.
It's also incorrect in a multithreaded environment
(there is a race between getruncount and schedule).
The other solutions already mentioned are better -
one way or another, use a channel.

> Based on stackless experience, an additional advantage I see is if the
> programme deadlocks(i.e., due to cycle), the loop gracefully
> terminates and one stands a fighting chance to run a deadlock
> detector.

The Go runtime already detects deadlocks and dumps
information about them.

Russ