go with confidence

In a previous post I discussed mux()ing, which is probably one of my favorite things.

Here I will show a fun application of mux()ing that I’m calling a LimitBuffer. It’s similar to a bytes.Buffer, except that it limits the amount of data stored in its buffer at any given time. Calls to .Write() will block until they no longer overflow the buffer. Calls to .Read() will block until there is data to read or the LimitBuffer has been closed.

Read More

original post

At one point, in the #golang IRC channel, I had occasion to explain why you cannot define a method on an interface type.

Here is the code whose behavior you can mull over.

package main

type Concrete int

func (c Concrete) Foo() {
    println("concrete foo")
}

func (c Concrete) Bar() {
    println("concrete bar")
}

type Interface1 interface {
    Foo()
}

func (i Interface1) Bar() {
    println("interface bar")
}

type Interface2 interface {
    Foo()
    Bar()
}

func main() {
    var c Concrete
    var i1 Interface1 = c
    var i2 Interface2 = i1
    i2.Foo() // prints "concrete foo"
    i2.Bar() // prints... what?
}

Read More

In much of the programming universe, the preferred method of synchronization between two or more concurrent processes is the mutex. And for good reason: mutexes (mutices?) provide a very simple tool that is easy to understand, and once you acquire that understanding you can use it to build arbitrarily complex concurrent systems.

Eventually.

The problem is that what you want as the programmer is rarely limited to exactly what a mutex gives you. Most of the time you need something a bit more complex, and although the more complex operation can be built out of mutexes, small errors become huge bugs which can be difficult to fix or even just observe (heisenbugs).

In this post I will demonstrate how to build a useful real-world concurrent system, first using mutexes and then using the more advanced tools that go offers.

the problem

The system in question is a notification multiplexor. One process, which I’ll call the Listener, will receive notifications from an outside source. Some number of other processes, which I will call the Subscribers, need to collect these notifications.

Read More

Sometimes a go programmer will wish for an infinitely buffered channel. Go does not offer any such construct, though by creating two channels and a goroutine to move data between them, it is possible to have infinitely buffered channel semantics.

Sometimes what people actually want is a channel that never blocks and never forgets. This isn’t quite the same as a channel with an infinite buffer. I didn’t mention anything about preserving the original message order, for one.

What you can do in the situation I describe is use something I’ve been calling a “stacked” channel. It’s a buffered channel with a special send operation and whose value type has a meaningful “join” function.

Read More