Skip to content

bufio: revert central buffer pool? figure out a plan for garbage. #6086

Closed
@rsc

Description

@rsc
CLs 8819049 and 9459044 should probably be reverted, and possibly replaced by something
else.

[Copy of response on CL 12687043.]

To expand on my comment, Go doesn't have Free because we have a garbage collector. The
garbage collector protects programmers from use-after-free bugs in their own code and in
code they are linking against.

It looks like an implicit "free" slipped in while I wasn't looking, in CL
8819049, and this just uses it in one more place. I believe that CL should be reverted,
along with CL 9459044. Unlike fmt's little reused buffer, there is API in both
bufio.Reader and bufio.Writer that exposes slices into the buffers to client code. A
badly written client might continue to read from or write to the slice after the buffer
is "freed", causing failures in completely unrelated pieces of code that just
happen to also use bufio.

I understand that you are after performance and buffer reuse, but there are safer ways
to achieve that when clients need it.

For example you could define a Reset(r io.Reader) on bufio.Reader and a Reset(w
io.Writer) on bufio.Writer, to allow clients to reuse a single bufio.Reader or
bufio.Writer for multiple of their own streams. If the client screws up, they shoot
themselves in the foot. With the current scheme, in which a client can "free"
a buffer into the general pool, a bad piece of code can shoot all the other code in the
foot.

This kind of thing is exactly why we removed runtime.Free.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions