Event queue processes and filling race.

[tcolgate]

We send the slice off to be process, but potentially start overwriting
the previous content straight away. Just start again with a fresh slice.

Fixes #247

[tcolgate]

It make be that it would be better to create a new sized slice to avoid the subsequent allocations during growth.

[claytono]

@tcolgate Agreed. The expectation in the existing code is that the slice is going to grow to the size needed, and once it does, future memory allocations can be avoided. Making a copy before sending it over the channel seems like the way to go.

[matthiasr]

That makes sense, a single reasonably-sized allocation is better than many smaller ones ending in the same size. We're trading a tiny bit of memory usage for low-traffic use cases but I think that is acceptable.

[tcolgate]

I see two options:

• make a new slice with the cap of the old one
• Always initialize the slice cap to flushThreshold and be done with it.

I vote for option 2 (for a busy server, I guess the degenerate to the same thing)

[matthiasr]

Always initialize the slice cap to flushThreshold and be done with it.

I think that's the best way.

[tcolgate]

@matthiasr I changed my mind, or rather, maybe we do both. This allocates the initial slice, and then just keeps copying the cap after that. This will cause something like 160KB of extra allocation on startup by default, I don't think people will notice.

[matthiasr]

Thank you!