On Thursday, October 27, 2016 at 6:35:40 PM UTC+3, Peter Mogensen wrote:
>
> It's a valid question whether Context is the concept to use for starting
> and stopping server instances. ... I'm not fully convinced. It seems to
> me it's more meaningfull for more transient things like Requests.
On Thu, Oct 27, 2016 at 8:21 PM, Diego Medina <fmpwiz...@gmail.com> wrote:
> 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).
>
That was my thought too, BUT (and this is what's nagging me) it is a fact that
using a context saves you from some subtle race-conditions that are present in
the Serve() / Shutdown() interface you 're proposing, and has much cleaner
semantics.
> Servers are basically started by calling Serve() ... which blocks until
> someone, somewhere invokes Shutdown()
>
> The whole daemon process can manage any number of objects implementing:
>
> type Server interface {
> Serve() error // start serving and block until exit
> Shutdown() // async req. to shutdown, must not block
> }
The "subtle races" I was talking about:
What happens if you call "Shutdown()" before you call Serve()? If the
answer is "nothing" then there is necessarily a small window of time,
after calling "Serve()" when shutdown calls will be ignored. So the
answer *has* to be: "the server will stop immediately after it's
started" (i.e. the server will "remember" the shutdown). Fine so far.
Now what happens if I want to re-start the same server after a
shutdown? Since the server remembers the shutdown, then the newly
started server will immediately stop. If the server somehow "clears"
the shutdown, just before terminating, then there is again a small
window of time, before the server returns, when the shutdown will be
inadvertently set for the *next* server run.
In effect, you need a third method (something like: "Reset()"). Which
must be called after the server shuts-down and before it can be
re-started. And of-course this has to be documented so that user can
understand these subtle issues...
Alternatively, you can make it impossible for the same server
instance to be started, once it has been shutdown... Which is not
something I like very much.
On the other hand, using a context to handle termination avoids these
issues: A context is in-fact a termination token associated with a
single *RUN* of the server. This solves all these pesky problems.
Any thoughts on this would be greatly appreciated...
/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.
