rittneje

`Accept`, `Accept-Encoding`, and `User-Agent` have nothing to do with session state. Only the `Connection: keep-alive` header really makes sense to be different since without a session I assume there's no...

To clarify, what I consider the issue here is not the existence of `Session.headers` itself, as in the ability to set headers on the session that get auto-applied to all...

I know this issue is from almost two years ago, but I just wanted to let you know there is actually a third way of specifying return values. You can...

This is a breaking change. Consumers that have to set close-on-exec on fds themselves may already be using `syscall.ForkLock`, and you cannot force everyone to replace `Lock` with `RLock` and...

No, `syscall.ForkLock` is a _public_ property that anyone can use. And this is required when you are working with lower-level APIs (e.g., `syscall.Socketpair`) and have to set close-on-exec yourself. Also,...

I'm assuming you meant to write `ForkLock.Unlock()` for the second block. I _think_ that will work.

Unfortunately, I think you'd have to be able to ask the `ForkLock` whether there are pending readers in order to avoid that, and currently that information is not exposed.

@ianlancetaylor This is the approach that @junchuan-tzh mentioned above. As discussed, it has an issue where if `forkExec` is continually being invoked it will prevent `syscall.ForkLock.RLock()` from ever unblocking.

Indeed, it is fairly complex. The choice of 10 as the concurrency limit (sort of) also seems very arbitrary. Perhaps `sync.Cond` would be a better choice than adding a channel?...

It should be noted that today you can also use anonymous functions for this. (Admittedly it can be a little awkward with return values, but at least you don't have...