You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A 3rd-party app that continually creates threads (similar to api.detach_spawn and other tests of ours, which are indeed flaky) can hang during static-DR attach: it hits the loop added for #2603 waiting on uninit_thread_count.
One solution is a full #1305 barrier where no threads make progress until all are attached, but I am worried about performance there for apps with many threads. Instead I'm putting in a new-thread barrier where no new threads in taken-over threads are allowed until attach is finished.
The text was updated successfully, but these errors were encountered:
Adds a barrier to taken-over threads creating new threads until attach
is fully finished. This avoids problems keeping up with an app that
is creating threads while we try to attach.
Fixes#3023
Adds a barrier to taken-over threads creating new threads until attach
is fully finished. This avoids problems keeping up with an app that
is creating threads while we try to attach.
Fixes#3023
Adds a barrier to taken-over threads creating new threads until attach
is fully finished. This avoids problems keeping up with an app that
is creating threads while we try to attach.
Fixes#3023
A 3rd-party app that continually creates threads (similar to api.detach_spawn and other tests of ours, which are indeed flaky) can hang during static-DR attach: it hits the loop added for #2603 waiting on uninit_thread_count.
One solution is a full #1305 barrier where no threads make progress until all are attached, but I am worried about performance there for apps with many threads. Instead I'm putting in a new-thread barrier where no new threads in taken-over threads are allowed until attach is finished.
The text was updated successfully, but these errors were encountered: