As a user of a package, if I "start it" by calling Start(), I will most likely look for a "Stop()" function but calling cancel on the context wouldn't feel natural because I'm not canceling the server, I would be done with it and don't need it any more).
Regards, On Thursday, October 27, 2016 at 10:11:34 AM UTC-4, Nick Patavalis wrote: > > Hi, > > I'm writing a package that allows the user to create and start server > instances. A server instance is created like this: > > srv := pkg.NewServer( ... params ... ) > > and started like this: > > err := srv.Start() > > Start does not normally return (unless an unrecoverable error > occurs). The user code can invoke Start() in a goroutine in order to run > multiple servers (which is not uncommon). > > I want to give the user-code the ability to stop servers when > required. One thought is to use "context.Context" for this purpose. That > is, the server could be started like this: > > ctx, cancel := context.WithCancel(context.Background()) > ... > err := srv.Start(ctx) > > and stopped by calling the "cancel" function of the context. > > I konw that, functionally, this will work. My question is: Does this > look like a "reasonable" / "idiomatic" use of contexts? Or will it > look "alien" to the user? I'm asking since the documentation of > "context" mentions it being used for "request-scoped" stuff, and this > is not exactly the case here. > > I can instead add a Stop() method to "srv" and roll-my-own stopping > logic. > > Which would you choose? > > /npat > -- 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.
