is it possible to call a function from inside a go-routine ?

[andreas graeper]

hi. i try to walk through a tree putting elems into channel

w(t,c) { if t!=nil { w(t.left,c) ; c<-t.elem ; w(t.right,c) }}

w0(t,c) { w(t,c); close(c); }

main(){

 go w0(t,c)

 for e := range c {}

}

if i drop 'close(c)' i get 'all threads dead' , otherwise 'write after close' 

it feels as if w is send to background too and i have to sync to the end of w before i close the channel ? 

thanks in advance, andi 

[Rishikesh Raj]

Yes you can because function are just code and the code you have mentioned works fine as what you have mentioned that if you remove close then for loop will run forever  as it might not able to find out whether the channel still have something to send and wait as channels sends 2 thing value and ok where okay tells whether the channels opened or close if you use close that ok becomes false and for loop terminates

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/4a665d05-d769-4249-a6df-4e3de0589d1an%40googlegroups.com.

[Def Ceb]

This happens because once you've walked and consumed every node in the entire tree, you're left with exactly one running goroutine, the one in the main function waiting for new elements in the channel. 

If you close the channel, the for loop closes. If you don't, it's the only thread left running and the runtime notices there are no new goroutines capable of doing anything. 

--

[andreas graeper]

hi. thanks for your answers. i understand that the channel has to be closed. what i do not understand is the error 'write after close' 

if w (called from w0) was executed in another thread, than i had to wait for the end of w by some mean of synchronization, before i close the channel. but if w0 and w are executed in same thread they are executed sequentielly inside the thread and close inside w0 is called when w has returned. so it should be fine. in main then for v := range c { } would end. 

[Def Ceb]

There are many options for this, depending on what you're actually trying to achieve.

For instance, you could have a waitgroup (from the sync package) shared between all producer and consumer goroutines, i.e those writing to and reading from the channel. Producers add to the waitgroup before writing, consumers mark a task as done after reading and processing a node. When the tree has been fully parsed and the waitgroup task count gets to zero, a goroutine blocking on waitgroup.Done() can then close the channel, causing the for loop to end.

That's a very basic approach, anyway. Look more into concurrent programming basics online.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/8b343e2a-ab29-4c33-8f3f-beb5b61ae09dn%40googlegroups.com.

[Rishikesh Raj]

See when we create w0 goroutine then a new thread will be generated so now we have 2 thread one main another w0 now from w0 we can w which will run of w0 thread and run sequentially so program will not execute in w0 till w not returned then ur channel close now at the time u have executed the w the function w keeps sending data to channel. now on that time main goroutine will wait untill the channel closes and which eventually going to close after close function after w returns to w0. So its the complete flow

--

[Marvin Renich]

* 'andreas graeper' via golang-nuts <golan...@googlegroups.com> [260608 05:43]:

People are having trouble helping you because you did not give a
complete, runnable example. You should use the Go Playground,
https://go.dev/play/, to demonstrate your problem, and use the "Share"
button to include a link to the code in your message.

For example, the code at https://go.dev/play/p/fu0r16PNocY demonstrates
the problem you are having, and from that it would have been clear to
the others who were trying to help you that the problem is on line 49,
where c is declared but not initialized. (Technically, it is
initialized to nil.) If you change that line to

var c = make(chan int)

then the code executes the way you expected.

The code you gave in your message was the part that was correct. It was
the part of your code that you did not include that contained the error,
so helping you required significantly more effort and a lot of guessing.
(I'm still guessing, but from your description of the symptoms, I have a
reasonable expectation that my analysis is correct.)

...Marvin

[Brian Candler]

On Monday, 8 June 2026 at 10:42:37 UTC+1 andreas graeper wrote:

w(t,c) { if t!=nil { w(t.left,c) ; c<-t.elem ; w(t.right,c) }}

w0(t,c) { w(t,c); close(c); }

main(){

 go w0(t,c)

 for e := range c {}

}

Note that "for e := range c {}" will keep reading elements from c *until the channel is closed*.  Therefore it's necessary to close the channel, after you've sent all elements on the channel - which is what you do in your w0() function.

> it feels as if w is send to background too and i have to sync to the end of w before i close the channel ? 

You can only close a channel *after* all goroutines have finished writing on it; otherwise you'll get the "write after close" panic that you describe. Your w0() function waits for w() to return, therefore all sends are complete, then closes the channel. That's fine.

The code you've sent is incomplete (it's missing types and keywords like "func"), but if I finish it, it seems to work:

https://go.dev/play/p/9jPj7dCi1nA

Therefore if it's not working, I suggest you make a self-contained example at https://go.dev/play/ which demonstrates your problem, and post the link here.

[Def Ceb]

Marvin, if you'll note the original message, it mentions that the deadlock only occurs if the close() (line 39 in your playground code) is commented out, indicating that this is not actually the case. 

Though yes, a runnable example is always nice.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/aibi2KAdNzkks/Bd%40basil.wdw.

[Marvin Renich]

* Def Ceb <mikk....@gmail.com> [260608 11:48]:

> Marvin, if you'll note the original message, it mentions that the deadlock
> only occurs if the close() (line 39 in your playground code) is commented
> out, indicating that this is not actually the case.
> Though yes, a runnable example is always nice.

It seems that in this case a runnable example is more than just "nice".
If you want help solving your problem, such an example is going be
necessary. Your description of the problem is lacking the details
necessary for any one to identify where the problem is.

...Marvin