Threads Suck

EventDriven architectures are overwhelmingly easy to switch to use threads, because the places between the events, for other activities, are also good places for semaphores. But this doesn't work the opposite way. Poorly architected systems might be hard to convert from threads to events. So, either way, focus on good architecture.

Well, my specific intention for this thread is for it to take care of caching the contents of a file in memory as my program is starting. The main thread can't wait that long, because the program is a Windows service and the service manager isn't willing to wait forever for my program to start. I know I could do this other ways, but is there really a big disadvantage to spawning a thread to handle the caching of this file?

Short term, no. Removing this thread won't force the architecture to improve.

Long term, use ReadFileEx() in asynchronous mode. If you need notification that the file arrived, you can multiplex the file event semaphore in with the window messages using MsgWaitForMultipleObjects().

Or start a window timer that wakes up and reads a small chunk of the file. The file system will buffer the real file asynchronously, behind these reads, meaning they shouldn't block the GraphicalUserInterface.

Notice the tutorials tend to teach threading _before_ they teach these high-powered methods to cleanly avoid threads...

--Phlip