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

Remove TestInotifyNoBlockingSyscalls #532

Merged
merged 1 commit into from
Nov 8, 2022
Merged

Remove TestInotifyNoBlockingSyscalls #532

merged 1 commit into from
Nov 8, 2022

Conversation

arp242
Copy link
Member

@arp242 arp242 commented Nov 3, 2022

This test checks if no additional OS threads are created; this was added after the old epoll-based inotify code was removed (which would create additional threads). It's always been a bit flaky: it currently already runs the test twice and "fails" only if both fail.

We don't really control the Go scheduler and when it creates/destroys OS threads, or have all that much insight in it (the "threadcreate" profile in pprof has been broken for years). I tried to make this test a bit more reliable a few months ago, and the run-it-twice "solution" was the best I could come up.

It still causes some failures though; see the links below. I don't know why it consistently fails on armle (and not e.g. arm64), but that seems a Go thing, rather than a fsnotify thing.

I'm not sure if this test adds all that much value; I don't really foresee a regression where we accidentally create more OS threads than we should.

Fixes #531
Also see: https://bugs.launchpad.net/ubuntu/+source/golang-fsnotify/+bug/1971967

This test checks if no additional OS threads are created; this was added
after the old epoll-based inotify code was removed (which would create
additional threads). It's always been a bit flaky: it currently already
runs the test twice and "fails" only if both fail.

We don't really control the Go scheduler and when it creates/destroys OS
threads, or have all that much insight in it (the "threadcreate" profile
in pprof has been broken for years). I tried to make this test a bit
more reliable a few months ago, and the run-it-twice "solution" was the
best I could come up.

It still causes some failures though; see the links below. I don't know
why it consistently fails on armle (and not e.g. arm64), but that seems
a Go thing, rather than a fsnotify thing.

I'm not sure if this test adds all that much value; I don't really
foresee a regression where we accidentally create more OS threads than
we should.

Fixes #531
Also see: https://bugs.launchpad.net/ubuntu/+source/golang-fsnotify/+bug/1971967
Copy link
Member

@horahoradev horahoradev left a comment

Choose a reason for hiding this comment

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

LGTM! If this test is causing us problems, yeah, let's just rip it out. The original issue has been fixed, and regression is unlikely.

@arp242 arp242 merged commit 0d1c834 into main Nov 8, 2022
@arp242 arp242 deleted the rm-ttest branch November 8, 2022 20:43
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.

TestInotifyNoBlockingSyscalls fail on arm
2 participants