Timeout does not work if native code is running at the time

[jnm2]

If you have native code running, Timeout has no effect. I assume this is because it relies on Thread.Abort.

Is there anything that could be done to improve this? A native way to nuke it if Thread.Abort does nothing?

[ChrisMaddock]

#1363 is probably relevant here. Just springs to mind as I came across it only a couple of days ago with regards to making Timeout available in the netstandard build, where System.Threading isn't available. I was previously considering a separate implementation using Tasks (which wouldn't be available in <net-4ish) - but sounds like a non-thread-based implementation of TimeoutAttribute could solve all three problems.

@CharliePoole - what thoughts did you have on the above issue, as its assigned to you?

[CharliePoole]

The intent of #1363 is to cancel the entire worker thread when there is a timeout, thereby eliminating the need for a "side thread" to run those tests with timeout. To do that, we need a way to add and remove workers smoothly while the tests are running. I think that's a general improvement to the dispatcher that we could use and I'd like to work on it.

Ideally, it would be great if we could deal with timeout in a different way. In that case, I'd re-title #1363 and just do the enabling bit, not the timeout.

Even if your implementation using tasks were only available in .NET 4+ and NetStandard, I think it would be a great improvement, so I say go for it!

[jnm2]

Timeouts also have no effect if the execution is inside a call to Application.Run(). My original question was kind of specialized because I was pinvoking MsgWaitForMultipleObjectsEx, but this is much more general of a problem.

[CharliePoole]

Are we just doing a simple Thread.Abort? We used to have code that did a bit more and took care of some of these cases.

[jnm2]

I would have expected Thread.Abort to work against the WinForms message pump, since I would have expected all waits and joins in the entire framework to be hardened for thread abort. But apparently Application.Run just calls either MsgWaitForMultipleObjectsEx or WaitMessage without waiting on any kind of 'thread abort' handle.

The solution seems to be kind of easy perhaps: just send a thread message to cause the native call to return, and the native to managed transition will abort the thread.

[jnm2]

For a workaround I'll try writing code that waits till the test timeout time elapses and then starts sending messages to the thread.

[CharliePoole]

If you find any new wrinkles that work, consider adding them to ThreadUtility.Kill, which is used to terminate threads on timeout.

[jnm2]

The proof of concept is working. I just need to replace my message-sending mechanism (threadSynchronizationContext.Post(_ => { }, null) with one that sends a native message and doesn't need a SynchronizationContext. NativeWindow requires a Windows.Forms reference, so I'll probably just pinvoke to post the message.

[jnm2]

PostThreadMessage WM_CLOSE is working well. This will work even without getting a SynchronizationContext which is good because they change.

[jnm2]

This solves my original problem and the Application.Run problem.

Here it is: https://gist.github.com/jnm2/190bf111ef418901d7abb7542cd0a6be
Definition of On.Dispose: https://gist.github.com/jnm2/a3219243836f20e5eb4f8ef777ae4e1c

Used as:

[Test, Timeout(2000)]
public void UI_test()
{
    using (MessagePumpTimeoutHelper.Start())
    {
        // ...
        Application.Run();
    }
}

[jnm2]

Next problem: Some tests are stuck in unmanaged code not at a message pool but inside a third party library which is spending most of its time in System.Globalization.CompareInfo.Compare(string, string, CompareOptions)'s native implementation. But I'm stepping in and out in the managed debugger, so why no ThreadAbortException?

[jnm2]

Fun fact: If thread A calls threadB.Abort, thread A is blocked until thread B cleanly aborts. If thread C comes along and TerminateThreads thread B, sure enough it's nuked, but now thread A is blocked forever and the test run still doesn't complete.

My conclusion: Let's not TerminateThread

[jnm2]

Probably the best thing for the test runner to do when a timeout happens is to fire and forget new Thread(() => thread.Abort()) { Name = "Aborting test X" }.Start(); and return and report each timeout failure as it happens even though the threads are still running. Then when all tests are done, the threads will go down with the process.

You could also consider passing a CancellationToken to test methods that have a parameter for it.

[jnm2]

Anyway @ChrisMaddock @CharliePoole (not sure which team to tag) I think that https://gist.github.com/jnm2/190bf111ef418901d7abb7542cd0a6be would be nice to merge into the test runner or framework, wherever the current Thread.Abort is. What are your thoughts?

[oznetmaster]

@jnm2 Never seen that happen, and it should not:

The Abort method is used to stop a managed thread permanently. When you call Abort, the common language runtime throws a ThreadAbortException in the target thread, which the target thread can catch. For more information, see Thread.Abort.
System_CAPS_noteNote
If a thread is executing unmanaged code when its Abort method is called, the runtime marks it ThreadState.AbortRequested. The exception is thrown when the thread returns to managed code.
Once a thread is aborted, it cannot be restarted.
The Abort method does not cause the thread to abort immediately, because the target thread can catch the ThreadAbortException and execute arbitrary amounts of code in a finally block. You can call Thread.Join if you need to wait until the thread has ended. Thread.Join is a blocking call that does not return until the thread has actually stopped executing or an optional timeout interval has elapsed. The aborted thread could call the ResetAbort method or perform unbounded processing in a finally block, so if you do not specify a timeout, the wait is not guaranteed to end.
Threads that are waiting on a call to the Thread.Join method can be interrupted by other threads that call Thread.Interrupt.