Subj : Threads are cool (was: Threads suck) To : comp.programming.threads From : Torsten Robitzki Date : Thu Jun 23 2005 01:42 am Christopher Benson-Manica wrote: > Phlip wrote: > > (Moving to comp.programming.threads - if you don't read that group, > come back to clc++...) > > >>Because I don't research OS kernels, embedded software, or other primitive >>spaces that need threads to get anything done, I have never seen a situation >>improved by a thread. Throwing a thread at a simple problem is worse than >>'goto'. If a button starts a process that takes too long, the process itself >>needs a better architecture. Agreed that "throwing a thread at a simple problem is worse than 'goto'", but in cases that a button starts a process that takes too long does not necessary mean that the process needs to be improved or can be improved. Some times it's as simple as having a button at all is the main design flaw ;-) > 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? Assumed that APIs for threading are more portable then APIs to asynchrone IO, a solution that spawns a thread for reading a big file in the 'background' while the main thread (or any other thread) can make a progress on solving a problem or providing a service seems quit viable and portable to me. One could even provide a quit portable interface to that file by blocking a thread until the data is read from the file, by what ever approach used, if that thread needs to read the file. regards Torsten .