20 May 2013 07:06
Applied reflection - an exercise.
As there is much talk /re generics, types, reflection and such in Go, I went through an exercise of making a very small library, which is in some sense is type-aware, yet is generic (as in common sense) in it's usage.
First and foremost, huge thanks to Ian Lance Taylor for the help during the Go office hours at Google I/O!!! Won't be able to do it without your help. Assignability of "chan interface{}" to "interface{}" was largely confusing initially.
The library's goal is to create a "fan out" channel facility with the following parameters (in no particular order):
1. All API (payload AND metadata) should be implemented in channels - no function calls.
2. The library should be usable as a part of error routing in an application.
3. One in-flow channel, unlimited out-flow channels.
4. Buffering fully controlled by a user.
5. Zero-configuration routing - data automatically forwarded to those out-flow channels which can accept it, skipped for other channels.
6. The facility can be garbage-collected.
7. The facility should not block on mis-behaving consumers regardless of their buffer.
The repository for my "answer" for the exercise is at https://github.com/didenko/pumps
Even if it was more of reflect package comprehension exercise, I have tried to produce the least code possible, as for production. There are a couple questions still lingering, which I can not yet answer. Before asking them, ehre is how the FanOut works:
* user specifies the in-flow buffer size in the factory function MakeFanOut(bufsize int)
* subscription happens by sending to Outs channel a channel to which forward values.
* post values by sending them into the Post channel.
* prevent future subscriptions by sending nil to the Outs channel
* shutdown the facility by sending nil to the Post channel
So here is the list of questions and concerns I have:
1. The two exposed channels accept nil as a control message. How does it correspond to common usage in Go?
2. Users' channels are closed on the facility shutdown. Given those supposed to be narrowly-typed (mostly) channels and not used anywhere else, seems to be a good idea. Or is it? Should I just leave users' channels alone?
3. Sending to user channels at dedicated goroutines is not guarded against non-reading consumers, potentially causing proliferation of idle goroutines. How would you suggest cleaning those up, if at all?
4. What else I miss?
As a general feeling about the reflection package, I ended up with a much simpler code than expected, which is great. Dealing with "interface{}"-typed channels was not obvious - it would be awesome someone more knowledgeable than myself to expand on it in The Laws of Reflection post - which is a must read by the way.
Cheers!
Vlad
-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
RSS Feed