Magnus Hagander said:
>
>>>Is that 100% correct? The way I read MSDN docs for SleepEx()
>>is that if
>>>there is at least one other thread running at any priority in the same
>>>process, the thread that calls SleepEx() gives up the remainder of its
>>>timeslice to that thread. This could have performance implications if
>>>other threads have to be created for some reason.
>>>
>>>
>>
>>If we catch the events in the main thread then there is
>>nothing else to
>>yield to. If we use a separate thread to catch them then it
>>should call
>>WaitForSingleObject instead of SleepEx, ISTM. In any case,
>>this couldn't
>>be handled by appropriate setting of thread priorities?
>
> The system will schedule a thread of equal priority *in any process*.
> Which means another backend, or even Solitaire (I beleive it doesn't
> change thread priorities) can be scheduled. (meaning we give up our
> timeslice, I may have been a bit unclear about that in my first mail)
>
Ahh. OK, I understand now.
> If we go with WFSO() in the main thread for the event sent from the
> other process, then the sending backends end up blocking until we
> actually pick up the signal. I think we're much better off with a
> separate thread that picks it up and queues a user APC for the main
> thread.
>
Given the above I agree at least that the event catching should be in a
separate thread.
If the handlers have thread safety issues one way could be have the event-
catching thread just set a flag and then check for it in the main thread,
which is a very common model for signal processing.
cheers
andrew