Tahir,

I'm new to go bit have done a lot of "messaging" (e.g. actors in Scala).

I *think* you need to change your thinking on this: forget about blocking
function call semantics. What you want (I think) is to protect one or more
resources, i.e. give only "atomic" access?

If that's the case then your solution would be:

1) a unique goroutine that reads from a channel and then performs logic
atomically (update the webcounter)
2) concurrent clients that write to the channel (trigger an update)

If the clients needs a return value it can pass in a channel in the request
which is unique to that particular client. This will have the effect of
blocking on the client goroutine as well (when it waits for the results to
come back).

What helps me with Go is if I think of goroutines of logic on top of queues
(channels).

--Maarten

Op dinsdag 11 september 2012 09:00:19 UTC+2 schreef Tahir Hashmi het
volgende: