Logging api

Reviewers:  @bernerdschaefer, @peterbourgon 

First pass at the internals of the logging API.  This is two layers thick.  There is a RingBuffer for log messages, and on top of this is a data structure that implements storage for and operations for each container.  (The RingBuffer probably should have been a separate submit.)

The next piece to be worked on will be the HTTP logging interface.
Done.


On Wed, Jul 30, 2014 at 6:18 PM, Peter Bourgon <notifications@github.com>
wrote:

> In harpoon-agent/logs.go:
>
> > +// Last retrieves the n last log lines from containerID, returning them in
> > +// the order from oldest to newest, i.e. []string{oldest, newer, ..., newest}.
> > +// The call is is idempotent.
> > +func (cl *containerLog) Last(n int) []string {
> > +	msg := logLast{count: n, last: make(chan []string)}
> > +	cl.lastc <- msg
> > +	return <- msg.last
> > +}
> > +
> > +// Listen subscribes a listener to a container.  New log lines to the subscribed container
> > +// are set to all of its listeners via their supplied logSink channels.  A logSink does
> > +// receive messages while it is blocked.  All of those messages are lost like tears in the
> > +// rain.
> > +//
> > +// The caller can subsequently use the ListenerID to remove the subscription.
> > +func (cl *containerLog) Listen(logSink chan string) ListenerID {
>
> I like the Notify/Stop idiom used by package signal
> <http://golang.org/pkg/os/signal/> and am trying to use it everywhere I
> want subscription semantics...
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/soundcloud/harpoon/pull/13/files#r15594409>.
>