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

Plans for supporting t.Parallel #4

Open
tsenart opened this issue Apr 28, 2016 · 7 comments
Open

Plans for supporting t.Parallel #4

tsenart opened this issue Apr 28, 2016 · 7 comments

Comments

@tsenart
Copy link

tsenart commented Apr 28, 2016

Hello!

Thanks for this library, it'll definitely come in handy. Would you be able to document the reasons why t.Parallel isn't supported and what ideas you have for addressing the problem?

Thanks

@fortytw2
Copy link
Owner

Thanks!

So right now, t.Parallel() isn't supported because goroutines from tests that run in parallel tend to show up in the deferred check - making it look like the current test leaks goroutines when it doesn't.

A potential solution I've had in mind is to have a variant of Check() that operates on a *testing.M, which is what the net/http tests do. I haven't had the chance to test it out yet though.

Another idea uses a sort-of context-aware, gross, package global stack-marker, but I don't think that'll pan out the way I'd like.

@tsenart
Copy link
Author

tsenart commented Apr 30, 2016

Thanks! :-)

@fortytw2
Copy link
Owner

Can track support for this in #16

Not entirely sure of this solution yet though

@pwaller
Copy link
Contributor

pwaller commented Jun 19, 2018

You guys might be interested in the recently implemented golang/go#22289. ("proposal: runtime: support tracking goroutine ancestor tracebacks").

Unfortunately I don't see a way of turning it on at runtime without spawning another process to set the environment variable to turn it on, hmm.

@bwplotka
Copy link

Looking forward for this to be done. Can I help anyhow? Any update? (:

@fortytw2
Copy link
Owner

I haven't worked on this in a long time @bwplotka, you're more than welcome to pick it up!

What I did two years ago was start allowing this via just add a TestMain( helper called CheckMain, that implicitly supports t.Parallel by just checking the entire program. Never got really far / found the need for it in any of my projects or work though, so I stopped using it.

For the last year now, the codebase I work on at $dayjob uses ginkgo, which has a parallel test runner that segments tests into independent binaries during parallel execution, which makes leaktest work as normal (but we don't have a real use case for it).

A solution based on what @pwaller noted last year would probably be the best way forward, feel free to give it a shot! You can message me on gophers slack (same username) if you want to chat about it

@bwplotka
Copy link

Awesome, will let know here if I will find time to work on this (: Thanks for tips! 👍

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

No branches or pull requests

4 participants