I have encountered a situation where a thread (say, thread-1) blocks for 10
minutes in an XmlSerializer constructor. This occurs when another thread
(say, thread-2) is blocked in a call to Console.ReadLine and the process was
created using System.Diagnostics.Process with RedirectStandardInput = true.
In this situation not only does thread-1 block for 10 min in the
XmlSerializer constructor, but will hang indefinitely when creating a COM
object.
The problem started occuring after migrating our application to .NET v2.0.
I found a forum post where some other developers have run into the exact
same problem. Please see this link:
http://forums.microsoft.com/MSDN/Sho...88895&SiteID=1 (it
also includes a reproducible testcase)
Is anyone aware of a decent workaround to this issue (or a fix available
..NET 2.0)? I seems that this problem greatly limits the usefulness of stdin
redirection.
BACKGROUND INFO
We need to run multiple instances of an console application (it runs until
told to stop). Since we need to run more than one process on a single machine
it did not make sense to make the application a windows service. Instead, we
developed a windows services that spawns these (child) application processes.
Using the System.Diagnostics.Process class we can not only spawn the process,
but also interact with it via stdin and stdout.
OTHER NOTES (not-so-nice workarounds)
It appears that the XmlSerializer hangs in the call to csc.exe (you can see
this child process using ProcessExplorer). I can get around this problem by
sgen'ing the assembly which eliminates the need for spawning csc.exe at
runtime. However, this doesn't fix the problem with creating COM objects.
Another workaround i've seen (see forum post mentioned above) is to not call
Console.ReadLine() in the child process. However, I need this call in order
to process interactive commandline input. Also note the call to ReadLine is
on an MTA thread to avoid STA "pumping" issues, so the deadlock/contention is
occuring on some other resource.
Similar Threads
