is to use a message channel and quit channel with a goroutine for each
device. When a JSON RPC request comes in, the device is found, and the
command is routed to the channel for the device. So far so good.
Then I ran into the problem where replies fail because the
http.ResponseWriter is closed once the goroutine from the web server exits.
This was quite surprising as it doesn't seem to be documented.
I'm not a big fan of satisfying web requests in the "thread" of the web
server as it means you have locking issues as multiple threads of control
must run through your objects. The Actor model cleans up all these locking
issues. But that's hard to do when the web server is closing resources you
need to reply.
It seems the server goroutine must be blocked until the device finishes the
operation, which could be an arbitrary time later is many requests may need
to be orchestrated to generate the reply.
What's the idiomatic way of handling this? I can think of:
1. a mutex to block the server goroutine that the device goroutine will
give when done. Seems clumsy to me.
2. like (1) but with a sync channel.
3. Change the RPC to be request oriented, so a 200 status is returned
immediately and the response is sent later to the sender in a later
request.
As I'm very much a Go newbie I was wondering what the smart Go way is to
handle these kind of issues?
thanks
--
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/groups/opt_out.