I'm using a RichTextBox control in a Windows Service to convert RTF to plain text. This method is actually mentioned by MS here: http://msdn.microsoft.com/en-us/library/cc488002.aspx

My Windows Service spawns multiple threads (typically 2 x the number of CPU cores), and each of these threads ends up instantiating a separate instance of the RichTextBox control and using it to convert RTF to plain text.

This seems to work great, except for when the service is run on machines with many cores. (4+). In these scenarios, the service will occasionally just lock up. The CPU spins at roughly 10%, and nothing happens. This will go on forever unless you kill the process. I finally managed to attach a debugger while it was happening, and it turns out it is something the RichTextBox control is doing. Looks like some internal lock that's placed when creating a new window handle.

I'm making sure that I dispose of the RichTextBox after every use. This doesn't seem to happen if I force the service to use fewer threads, but this dramatically reduces the throughput of my service on multi-core machines.

Anybody have any ideas on how to fix this, or any idea on a better way to convert RTF to plain text?

Here is the relevant portion of thestack trace of one of the threads that's stuck:

I've actually tried to use that one before. Even with a simple RTF document it doesn't seem to work... just get lots of exceptions.

I've made some attempt to resolve the exceptions, but to be honest, the code is a classic example of over engineering, over refactoring, and over reliance on programming patterns. The thing has so many levels of indirection that it's nearly impossible to figure out exactly what's going on.

Got any others? :)

Such a thread has to be initialized correctly. Call Thread.SetApartmentState() to switch it to STA before you start it. And call Application.Run() to pump a message loop. Control.Invoke() is required to set any of the properties. You can't use a threadpool thread.

---

Hans Passant.

    public class RTFConverterPool
    {
        private readonly object m_RTFConverterPoolLock = new object();
        private Dictionary<int, RTFConverter> m_RTFConverterPool;

        public RTFConverter ThreadSafeRTFConverter
        {
            get
            {
                RTFConverter rtfConverter;
                int currentThreadId = Thread.CurrentThread.ManagedThreadId;

                lock(m_RTFConverterPoolLock)
                {
                    if(m_RTFConverterPool.ContainsKey(currentThreadId))
                    {
                        rtfConverter = m_RTFConverterPool[currentThreadId];
                    }
                    else
                    {
                        rtfConverter = new RTFConverter(string.Empty, 800, 0, 0);
                        m_RTFConverterPool.Add(currentThreadId, rtfConverter);
                    }
                }

                return rtfConverter;
            }
        }<br/>

Each thread in my thread pool then calls the ThreadSafeConverter property to get its own thread-specific instance.

The code seems to work, although I haven't run enough testing to know if it resolves the original problem of having the service lock up. It's difficult for me to reproduce this on my desktop.

Why do I need to set the aparterment state to STA? It was my understanding that this was only required for COM interop. (Which, I guess, the RichTextBox could be using internally.) Also, what will Application.Run() do for me in this instance? Are you thinking that the RichTextBox needs to have a message loop running for this locking not to occur?

If only the thread that creates the RichTextBox ever accesses it, I'm assuming I don't need to use Invoke.

(yes), yes and yes.

---

Hans Passant.