[omniORB] Windows timeout during ORB shutdown

[Thomas Ives]

On 30/01/2026 16:58, Duncan Grisby wrote:

> That is interesting, but I think it is too fragile to use here. In your
> test, all the connection worker threads are blocked in select, but in
> general there is no way to know if the worker threads are in select at
> the time, or whether they are busy doing some other work that might be
> damaged by the asynchronous call.

The APC will only be called when the thread is supposed to be sleeping, 
or in what Windows calls an "alterable state", so there is no chance of 
damaging any work the thread is doing.  From [1]:

 > When a user-mode APC is queued, the thread to which it is queued is 
not directed to call the APC function unless it is in an alertable 
state. A thread enters an alertable state when it calls the SleepEx, 
SignalObjectAndWait, MsgWaitForMultipleObjectsEx, 
WaitForMultipleObjectsEx, or WaitForSingleObjectEx function.

> Real servers, as opposed to test code, are not expected to rapidly
> start and stop repeatedly, so I don't think the additional significant
> complexity to make it faster would be a good idea.

Indeed, I think it is fair to say it isn't worth the complexity cost to 
interrupt the threads on Windows.

> I'm going to commit the attached small change. I suggest that for your
> test code you set scanGranularity to 1. That will mean it takes a
> second to stop, which is still quite long, but faster than the default
> 5 seconds.

Thanks for the patch.  Although this is not ideal for our case, I still 
think this will speed our Windows tests up significantly.

Thanks

Thomas

[1] 
https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls