Not sure about how timers are structured, but I assume they are not thread safe. They likely are bound to the main thread, not the calling thread.
Events are definitely NOT thread safe. Events are pulled from, and push to a que, and that que is not handled in a thread safe manner. (even if you wrapped your polling commands to be thread safe when events are created they are not inserted safely so you could still "cross the beams").
It is possible to post events (and one could extrapolate polling as well) from a thread, but you have to wrap the action in a main thread handling routine. e.g.
Child thread wants to post an event. So it creates the event and, in a thread safe manner shoves it into a tlist.
The main loop every cycle examins the tlist (again in a thread safe manner) and if it finds anything it posts the event.
I use this method in one of my applications, however you have to let the main loop cycle and poll events yourself rather than waiting on them. OR you have to be confident that something will trigger you waitevent to process (such as moving the mouse) which gives you an opportunity to post those other events. This is preferable from a resources standpoint (much less processor time spent cycling) but obviously until one event happens, allowing the child created events to get posted, then they don't exist.
|
