Because of issues with glibc, using the os/user package can cause when
calling user.Current(). Neither the Go maintainers or glibc developers
could be bothered to fix it, so we have to work around it by calling the
uid and gid functions directly. This is probably better because we don't
actually use much of the data provided in the user.User struct.
This required some refactoring to have better control over when the uid
and gid are resolved. Rather than checking the current user on every
connection, we now resolve it once at initialization. To test that this
provided an improvement in performance, a benchmark was added.
Unfortunately, this exposed a regression in the performance of unix
sockets in Go when (*UnixConn).File is called. The underlying culprit
of this performance regression is still at large.
The following open issues describe the underlying problem in more
detail:
Because of issues with glibc, using the
os/userpackage can cause when callinguser.Current(). Neither the Go maintainers or glibc developers could be bothered to fix it, so we have to work around it by calling the uid and gid functions directly. This is probably better because we don't actually use much of the data provided in theuser.Userstruct.This required some refactoring to have better control over when the uid and gid are resolved. Rather than checking the current user on every connection, we now resolve it once at initialization. To test that this provided an improvement in performance, a benchmark was added. Unfortunately, this exposed a regression in the performance of unix sockets in Go when
(*UnixConn).Fileis called. The underlying culprit of this performance regression is still at large.The following open issues describe the underlying problem in more detail:
https://github.com/golang/go/issues/13470 https://sourceware.org/bugzilla/show_bug.cgi?id=19341
In better news, I now have an entire herd of shaved yaks.
Signed-off-by: Stephen J Day stephen.day@docker.com