> ...But within a single process it is un-necessary. Either store the handle > somewhere global (ugly but fine for small apps). > Or pass the event handle to your thread procedure (along with all of its > other arguments) in the LPVOID argument of > the thread proc.
Hmmm... I guess the process handle params of DuplicateHandle() should have been my clue... so using an event handle across multiple threads from the same process is perfectly safe? This seems to differ from using, say, window handles across threads, which is why I thought I would need duplication. I thought all handles were similar in nature and thus required safe handling across threads even within the same process. > Without knowing exactly what you are doing, and ignoring the > un-needed duplication > this seemed fine. The worker thread is running in a loop, waiting until an event happens, or it is told to terminate. > Remember that you can just let a thread exit. When it does the > thread handle > becomes signalled. You can wait > for this just as easily as an event. See above - I need to tell it to end its loop. > > Of course this does mean that you will have to go through the procedure > of > starting up a new thread the next time you want one. Depending on > how frequently > you're going to be doing this > you may find this wasteful of CPU resources. I feel this would be wrong for my case, since the events being waited for are frequent and constant more or less the lifetime of the app. -- Jason Teagle [EMAIL PROTECTED] _______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
