On Oct 28, 2016 14:48, "Peter Mogensen" wrote:
>
> So ... bottom line ... defining Server objects as one-shot/single-use
allows you to define the Kill()/Shutdown() semantics to simply exhaust that
single-use. (an being idempotent) ... making it irrelevant whether the
server has actually been start
On 2016-10-28 13:32, roger peppe wrote:
On 28 October 2016 at 11:03, Nick Patavalis wrote:
In fact the worker "w" is a single-use thing much like a context.
Yes, that's right. The main difference from a context is that a context provides
no way to know when things shut down. This, I think,
On Oct 28, 2016 14:32, "roger peppe" wrote:
>
> Yes, that's right. The main difference from a context is that a context
provides
> no way to know when things shut down. This, I think, is by design - things
> like ErrGroup provide that functionality when needed.
Yes, exactly.
/npat
(sent from my
On 28 October 2016 at 11:03, Nick Patavalis wrote:
> In fact the worker "w" is a single-use thing much like a context.
Yes, that's right. The main difference from a context is that a context provides
no way to know when things shut down. This, I think, is by design - things
like ErrGroup provide
By considering the server creation and starting out-of scope, rog's
approach in-effect assumes that a worker instance is the same as a worker
"run". Once a worker "w" is created it is considered "running" and once
it's stopped, there is no way to re-start it. You must create a new
instance. This si
On 2016-10-28 10:37, roger peppe wrote:
FWIW we often use an interface named Worker for long lived processes,
including servers:
type Worker interface {
Kill()
Wait() error
}
Kill asks the worker to die but doesn't block.
Wait waits for the worker to die and returns an
FWIW we often use an interface named Worker for long lived processes,
including servers:
type Worker interface {
Kill()
Wait() error
}
Kill asks the worker to die but doesn't block.
Wait waits for the worker to die and returns any error encountered while
running.
Creation
On 2016-10-28 09:09, Nick Patavalis wrote:
On Fri, Oct 28, 2016 at 8:15 AM, Peter Mogensen wrote:
The point being that it's up to the user of the interface how to specific
Server implementation should work.
Yes, of course, but an interface with just two methods (Serve / Stop)
is not enoug
On Fri, Oct 28, 2016 at 8:15 AM, Peter Mogensen wrote:
>
> The point being that it's up to the user of the interface how to specific
> Server implementation should work.
>
Yes, of course, but an interface with just two methods (Serve / Stop)
is not enough to provide race-free semantics (unless yo
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() me
On Thu, Oct 27, 2016 at 11:11 PM, Peter Mogensen 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 acknowl
On 2016-10-27 21:34, Nick Patavalis wrote:
These is no way to (positively) know when the server will enter the
"running state". Think of this sequence:
go func () {
err := srv.Serve() // or .Start()
srvEnd <- err
}
... a short time after ...
srv.Stop() // Ser
Hi,
On Thu, Oct 27, 2016 at 9:34 PM, Peter Mogensen wrote:
>
> Technically that depends on the Server implementation.
> But in the provided http.Server extension, the answer is "nothing":
>
> func (srv *Server) Shutdown() {
> srv.runlock.Lock()
> defer srv.runlock.Unlock()
>
On 2016-10-27 19:32, Nick Patavalis wrote:
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
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
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
16 matches
Mail list logo
