3 ms·

IMHO, there is a subtle difference between your version and the version posted. You assuming a "real" producer-consumer relationship. But the posted code seems

by taway2012 13y ago

IMHO, there is a subtle difference between your version and the version posted. You assuming a "real" producer-consumer relationship. But the posted code seems to imply a sort of "supervisor-worker" relationship. The "supervisor" "snoops" on the worker's state and raises an alarm if the worker is doing something weird. As you stated at the end, synchronizing around currentPos seems to be most reasonable solution (assuming that's possible). That guarantees that no Point method is running while currentPos's state is being examined.

zemo 13y ago
I'm under the impression that the supervisor wants to stop the worker as soon as its doing something wrong; not do something like check every so often, and stop only when the supervisor notices. Anyway, what you're describing is pretty easy too. Basically all you do is make a channel of Point, and have the supervisor read on that. The worker just does some work, and tries to send his value down the channel. If someone's listening, send the value. This is pretty straightforward, but probably not safe in the real world, because the worker just keeps on working; it doesn't wait for a confirmation that its work is ok. http://play.golang.org/p/J8Xgh8S18b http://play.golang.org/p/J8Xgh8S18b If you want to structure it such that the supervisor can stop the worker, ask the worker what it's doing, look at the data, and then reply with "ok, you can continue now", there's a handful of ways to do it. Now we're getting pretty real-world, and things get a little bit more intricate, but you can do it like this: http://play.golang.org/p/hXYNmCm8lg http://play.golang.org/p/hXYNmCm8lg the trick being that you send a channel over another channel. There's a handful of ways you could structure this; there may be a cleaner way.

3 ms·

IMHO, there is a subtle difference between your version and the version posted. You assuming a "real" producer-consumer relationship. But the posted code seems

by taway2012 13y ago

zemo 13y ago
I'm under the impression that the supervisor wants to stop the worker as soon as its doing something wrong; not do something like check every so often, and stop only when the supervisor notices. Anyway, what you're describing is pretty easy too. Basically all you do is make a channel of Point, and have the supervisor read on that. The worker just does some work, and tries to send his value down the channel. If someone's listening, send the value. This is pretty straightforward, but probably not safe in the real world, because the worker just keeps on working; it doesn't wait for a confirmation that its work is ok. http://play.golang.org/p/J8Xgh8S18b http://play.golang.org/p/J8Xgh8S18b If you want to structure it such that the supervisor can stop the worker, ask the worker what it's doing, look at the data, and then reply with "ok, you can continue now", there's a handful of ways to do it. Now we're getting pretty real-world, and things get a little bit more intricate, but you can do it like this: http://play.golang.org/p/hXYNmCm8lg http://play.golang.org/p/hXYNmCm8lg the trick being that you send a channel over another channel. There's a handful of ways you could structure this; there may be a cleaner way.