[PATCH 0/2] MR127: ws2_32: Make wait in select alertable

[Paul Gofman]

On 5/25/22 10:48, Jacek Caban wrote:
> On 5/25/22 17:36, Paul Gofman wrote:
>> On 5/25/22 10:28, Jacek Caban wrote:
>>> On 5/25/22 04:00, Paul Gofman (@gofman) wrote:
>>>> Thus the second patch. In the ideal case we'd probably want to 
>>>> avoid crashing or handle segfault in system APC processing somehow, 
>>>> but I don't yet see a feasible way to do it. In theory the same may 
>>>> happen without ws2_32 if the app does the same, but I don't know 
>>>> that anything hits that case while ws2_32 queues those on stack 
>>>> iosbs, so avoiding that may probably avoid the practical issues.
>>>
>>>
>>> On Windows, asyncs are terminated when owning thread is terminated. 
>>> If we supported that and made sure that it happens before thread 
>>> stack is deallocated, it should solve the problem.
>>>
>>>
>>> Jacek
>>>
>>>
>> Do you mean, e. g., if a thread has called an overlapped 
>> DeviceIoControl() (or queued other overlapped IO) and exited, the 
>> other thread waiting for it to complete, e. g., with 
>> GetOverlappedResult() or waiting for event it will never get the 
>> completion?
>
>
> I think that wait should complete. It's been a while since I looked at 
> it, but AFAIR it looked like we should do something like 
> cancel_process_asyncs() for each thread separately.
>
>
I can test that, but my impression (maybe wrong) was that I can exit the 
thread which queued the IO and still get the operation successfully 
completed and the IO status received on another thread after.


But imagine that the thread which got an exception in an APC from 
select() did not exit but just got unwound through exception. In that 
case processing system APC won't crash but will corrupt the stack by 
writing the IO status. Should not we better avoid on-stack IO status 
regardless?