x/tools: unify I/O semaphores

[josharian]

grepping for the word "semaphore" reveals five separate I/O semaphores in x/tools. Some of them could easily be used in the same executable, e.g. those in go/loader, go/buildutil, refactor/importgraph, and cmd/guru. This makes them less effective.

I suggest we add a single exported semaphore to x/tools, which all x/tools packages can import and use, thus providing an actual process-wide limit on I/O concurrency. It could be in an internal package or not; I don't feel strongly.

cc @bradfitz @alandonovan @kevinburke for opinions

[josharian]

And searching for make(chan struct{}, finds three more.

[kevinburke]

I don't feel strongly about it! I actually maintain a semaphore package but don't care if we use it. https://github.com/kevinburke/semaphore

[alandonovan]

An internal package sounds fine. If I could redo x/tools, I would export a fraction of the APIs it currently has.

[josharian]

Great, will do. Anyone want to bikeshed API details before I send a CL? For lack of better names, perhaps:

Package: golang.org/x/tools/internal/iosem

Exported API: Acquire() and Release()

Allowed concurrency would be fixed at 20.

Usage would look like:

iosem.Acquire()
// do work
iosem.Release()

[josharian]

Alternative package names: iolimit, iogate. Alternative func names: Enter/Leave, Enter/Exit.

[gopherbot]

Change https://golang.org/cl/108878 mentions this issue: cmd/guru: parallelize loop in globalReferrersPkgLevel

[agnivade]

iosem and .Acquire()/.Release() sounds fine to me.

Should we perhaps expose the concurrency ? Or make it fixed at 20 ?

[josharian]

We can expose the concurrency later if there is a reason to. We use 20 most other places in x/tools, and hard-coding it for now is simpler.