Vincent Ladeuil wrote:
> Thanks for investigating the problem.
>
> Leaked threads are known about, selftest will even report about them (when it
> can finish that is).
> The crash with "can't start new thread" is pretty new though but is also
> blocking the test suite to run under cygwin.
>
> As you discovered, some threads can be garbage collected, some others can't.
> Most of them though are caused by test server threads and we can't easily
> terminate them due to our transport objects design. This is known and there
> may even be a bug filed about adding a close() method for them.
Probably we should change SmartTCPServer to track the smart-server-child threads
it starts and .join them all in stop_background_thread, at least for
SmartTCPServer_for_testing. The tradeoff here is that it might hang in some
circumstances, but I suppose we can use the timeout param of Thread.join to
mitigate that.
Vincent Ladeuil wrote:
> Thanks for investigating the problem.
>
> Leaked threads are known about, selftest will even report about them (when it
> can finish that is).
> The crash with "can't start new thread" is pretty new though but is also
> blocking the test suite to run under cygwin.
>
> As you discovered, some threads can be garbage collected, some others can't.
> Most of them though are caused by test server threads and we can't easily
> terminate them due to our transport objects design. This is known and there
> may even be a bug filed about adding a close() method for them.
Probably we should change SmartTCPServer to track the smart-server-child threads _thread, at least for for_testing. The tradeoff here is that it might hang in some
it starts and .join them all in stop_background
SmartTCPServer_
circumstances, but I suppose we can use the timeout param of Thread.join to
mitigate that.