On Thu, Oct 27, 2016 at 11:11 PM, Peter Mogensen <a...@one.com> wrote:
>
> The problem you seem to be trying to solve here is for the caller of
> Shutdown() to know when the Server has exited Serve().
> The way to do that under "my" semantics to implement a Server letting you
> wait for it to be ready to acknowlede Shutdown()
>
> A Serve() implementation could be done in many ways (it doesn't have to
> drop Shutdown() ) ... to to extend the example it could easily once in
> running state send an event on a channel you could wait on (or use a
> CondVar)
>
> So ...
>
> func (s *Server) Serve() {
> runmu.Lock()
> s.running = true
> runmu.Unlock()
>
> s.IsRunningChan <- true
> ....
> }
>
> go func () {
> err := srv.Serve()
> srvEnd <- err
> }
>
> ... a short time after ...
>
> <- srv.IsRunningChan
>
> srv.Stop()
>
> <- srvEnd
>
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.
>> No problem. Under "my" semantics, once you call Shutdown() on a server
>> instance it cannot run again, unless you explicitly call Reset().
>
> Oh... I thought you argued against the 3rd method.
>
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.
> since you cannot call CancelFunc() twice ... (closing a closed
> channel will panic).
You call the "cancel" function of a context as many times as you
want. But this is besides the point... Naturally, every time you stop
and re-start your server you must update your cancel func, most likely
under a lock.
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.
/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.
