My goal is to have a long polling handler that waits on a sync.Cond.
I also want to stop waiting if the client stops the connection, to avoid
having ghost goroutines hanging around.
This simple idea quickly became hell.
First, I cannot put a cond.Wait() in a select case (only channel operations
are allowed). As a result, having the Wait() timeout in case of a receive
on the notify channel becomes non-trivial; what I did was spawn a new
goroutine to listen on the channel, and trigger a cond.Broadcast() in case
something happened.
Secondly, the notification channel is not closed when the request
completes. This means that the goroutine that was listening to this channel
was now hanging if the user didn't stop the connection. I solved *this* problem
with another timeout channel, feeded when the request completes, and read
as an alternative case alongside the close notification channel...
So, even though this wouldn't make my function as pretty as I'd like, I
think closing the channel returned by http.CloseNotifier could be a good
idea. The channel already returns a boolean (true in case of a closed
connection), so having it return false if the request completes
successfully would still allow to differentiate these two situations.
I'm open to any comment or idea.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.