-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Locking finalizer keeping app alive #314
Labels
Milestone
Comments
This isn't specific to ConcurrentBag. The same pattern it employs with a finalizer that locks has the same behavior: using System;
using System.Threading;
class Program
{
static void Main()
{
new Thread(() => { while (true) GC.KeepAlive(new Finalizable()); }) { IsBackground = true }.Start();
Console.WriteLine("Going to sleep");
Thread.Sleep(TimeSpan.FromSeconds(3));
Console.WriteLine("Woke up!");
}
}
class Finalizable
{
private static readonly object s_lock = new object();
~Finalizable()
{
lock (s_lock) { }
}
} |
AndyAyersMS
added a commit
to AndyAyersMS/runtime
that referenced
this issue
Jan 15, 2020
Make STRESS_GENERIC_VARN more compatible with methods that make explicit tail calls. Don't add gc checks for explicit tail calls, and remove the code in morph that blocks tail calls if gc checks are active. Update the tailcall test to to disable STRESS_UNSAFE_BUFFER_CHECKS. This can be reverted when dotnet#314 is merged. Fixes dotnet#1752.
I assume this is not a regression so I have set milestone to future. Feel free to pull it back to 5.0 otherwise. |
jkotas
added a commit
to jkotas/runtime
that referenced
this issue
Jul 8, 2020
The finalization queue can be long or constantly growing when the finalization thread is not able to keep up with finalizable object allocation rate. This can lead to shutdown being blocked for a long time or indefinitely. The fix is stop the finalization loop once we enter shutdown instead of trying to empty the finalization queue. Fixes dotnet#314
jkotas
added a commit
that referenced
this issue
Jul 8, 2020
The finalization queue can be long or constantly growing when the finalization thread is not able to keep up with finalizable object allocation rate. This can lead to shutdown being blocked for a long time or indefinitely. The fix is stop the finalization loop once we enter shutdown instead of trying to empty the finalization queue. Fixes #314
adamsitnik
added a commit
to dotnet/BenchmarkDotNet
that referenced
this issue
Oct 23, 2020
so we need to dispose them after we are done running the benchmarks see #1383 and dotnet/runtime#314 for more
AndreyAkinshin
pushed a commit
to dotnet/BenchmarkDotNet
that referenced
this issue
Oct 26, 2020
…nting the results (#1571) * add test * dispose unused dispsable parameters * stop the benchmark process output stream processing after receiving the last signal * don't try to read the standard error as it might also hang the benchmark process is catching all exceptions and writing to standard output, so it's OK (this is what the class Executor does already) * kill benchmarking process if it does not quit within 250ms after finishing benchmarking * exit code can be != 0 for benchmarks that have executed fine but hanged after printing the results * some benchmarks might be using parameters that have locking finalizers so we need to dispose them after we are done running the benchmarks see #1383 and dotnet/runtime#314 for more
MichalStrehovsky
pushed a commit
to MichalStrehovsky/runtime
that referenced
this issue
Nov 10, 2020
Merge from dotnet/runtime
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
While working on dotnet/performance#1049 I've found that following app never quits:
@stephentoub is this expected behavior?
edit: simpler repo
The text was updated successfully, but these errors were encountered: