On 2016-10-27 22:50, Nick Patavalis wrote:
Yes, this would work, as demonstrated by your example, which is correct. But this further complicates the semantics and the interface. Now you also need a way to wait for the server to become running. In effect, you need something like a WaitStart() method, in addition to Serve()---if you want your interface to be used in a race-free manner.
The point being that it's up to the user of the interface how to specific Server implementation should work.
I was arguing that: You need a Reset() method (or a WaitRun() like above) otherwise your interface's semantics are inherently racy. This is complicated to explain. On the other hand, the user is already accustomed with the semantics of cancelation through contexts, which are race-free.
... but in that case you need a global registry of contexts to hook them up against signalling.
So I guess my conclusion is: Contexts could be used to stop servers, solving issues with racy semantics, but since, as it turns out, this is not a customary practice, it may confuse the users.
As I said before... what they buy you is a way to provide the channel used for shutdown externally, so you know exactly which invocation of Server() you are cancelling. But when the shutdown event is triggered externally, you need some extra code to provide the context for the current Serve() invocation.
You are correct that in my library some signals can get lost... if you send a SIGTERM quickly followed by a SIGINT it could be that the SIGINT is lost due to SIGTERM having but all Servers in a non-running state.
... or (and this is much worse)... maybe only some of them. I'll probably have to look into that. /Peter -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
