Workaround for .NET Remoting TcpChannel Timeout Issue

Question

Since I (and many other people on the internet) are unable to configure the client-side TcpChannel timeout when using .NET Remoting (please don't suggest proper fixes, I've literally tried everything, and no WCF suggestions please), I have come up with what seems like a decent workaround to creating a client-side timeout we can configure. If I feed each Remoting call through a separate timer thread, and the call either times out or throws an Exception, then I can kill the thread and assume that the server is down.

However, I ran this by another co-worker, and he was adamant that I could cause a deadlock in the native machine code of .NET by doing this. I've read other instances of this type of technique working on the internet like this post here, so I am unsure if worrying about a deadlock is really something I should have to worry about here. I can see it maybe being a problem if the thread were to abort in the middle of sending or receiving something, but not if we're just waiting on a response.

Answer 1

Since Dan didn't post an answer, only commented, I attribute this answer to him. It seems that this method of managing a timeout is fine, as long as you take precautionary steps to ensure the thread execution does not continue in the event of a timeout. I also recommend against using Thread.Abort unless you know what you are doing.