Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update elastic/go-windows && add open handles count #27

Merged
merged 5 commits into from
Sep 11, 2018

Conversation

kvch
Copy link
Contributor

@kvch kvch commented Sep 4, 2018

  • update elastic/go-windows
  • add OpenHandleEnumerator and OpenHandleCount instead of FileDescriptor
  • implement OpenHandleCount on Windows

types/process.go Outdated
@@ -44,6 +44,10 @@ type FileDescriptor interface {
FileDescriptorCount() (int, error)
}

type OpenHandles interface {
OpenHandlesCount() (int, error)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this differ enough from FileDescriptor to justify it being its own type? To me knowing the FD count is the same thing as knowing the Handle count, but perhaps I don't understand the differences.

If not implementing the FileDescriptors() part of FileDescriptor is the issue then you could decompose the interface more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I introduced a new interface, so if in the future we want to add something platform specific, we don't need to split it. Although file descriptor and file handles are nearly the same, I would not use the same or the current interface. What do you think about another name which is not tied to any platform? For example ProcessOpenFiles? Or separating the interface into OpenFileCounter and OpenFileEnumerator? Or OpenFileCounter and OpenFilesLister?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about another name which is not tied to any platform?

Yes, I'd like this. I think "handle" is a more generic name than "file descriptor" given that it encompasses more things than just files.

Although file descriptor and file handles are nearly the same, I would not use the same or the current interface.

I agree about not using the current interface, but as a user I would want to use the same interface (or interfaces) to get this data from all platforms.

Or separating the interface into OpenFileCounter and OpenFileEnumerator?

That's pretty close to what I'm thinking, but with the term "Handle" instead of "File" because it's not just files being counted.

type OpenHandleCounter interface {
    OpenHandleCount() (int, error)
}

type OpenHandleEnumerator struct {
    OpenHandles() ([]string, error)
}

types/process.go Outdated
@@ -44,6 +44,10 @@ type FileDescriptor interface {
FileDescriptorCount() (int, error)
}

type OpenHandles interface {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add godocs with all new types and methods. The project has some tech debt in this area but no need to add to it.

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Just the one minor comment.

@@ -276,3 +276,15 @@ func (p *process) CPUTime() (types.CPUTimes, error) {
System: windows.FiletimeToDuration(&kernelTime),
}, nil
}

// OpenHandles returns the number of open file handles of the process.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think file should be removed from this particular description.

@kvch kvch merged commit 7b02149 into elastic:master Sep 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants