RFR 8059533: (process) Make exiting process wait for exiting threads [win]

[David Holmes]

Thanks Ivan - good to go.

David

On 29/10/2014 8:56 PM, Ivan Gerasimov wrote:
>
> On 29.10.2014 13:15, David Holmes wrote:
>>
>> Great improvement thanks! One further suggestion - after line 3731 add
>> a short overview eg:
>>
>> // Basic approach:
>> //  - Each exiting thread registers its intent to exit and then does so.
>> //  - A thread trying to terminate the process must wait for all
>> //    threads currently exiting to complete their exit
>>
>>
>> Typo:
>> 3802           // _endthreadex() comleted.
>>
> Thanks! Fixed the typo and added the comment.
> The updated webrev is at the same location:
> http://cr.openjdk.java.net/~igerasim/8059533/1/webrev/
>
>>
>>>>
>>>
>>> I have a couple of thought about this:
>>>
>>> First, the thread that ends the process waits for all the exiting
>>> threads to complete. By the time it returns from WaitForMultipleObjects,
>>> those exiting threads aren't running anymore, so the race is avoided
>>> (unless it's the race with scheduler).
>>
>> That's not quite true and the key part of my point. At some point
>> during the thread termination process the exiting thread has to signal
>> any waiting thread - and it is still running at the point. We don't
>> know whether the action that causes interference with the process
>> termination happens before or after the signalling is done.
>>
> I was thinking if the dedicated scheduler thread can do the signalling.
> Otherwise, some poorly behaving thread could die without updating its
> status, leaving other threads waiting for its completion forever.
> Though, I don't know how it's actually done.
>
> I've read in several places (for example, a comment at the bottom of
> [1]), that waiting for a thread to complete with WaitForXXX() function
> ensures the exit code of that thread is set. In particular,
> GetExitCodeThread() should not return STILL_ACTIVE for that thread anymore.
>
> This lets me hope that the code, which sets the exit code (which is
> potentially racy) has already been executed by the time WaitForXXX()
> returns.
>
> [1]
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683190(v=vs.85).aspx
>
>
>> Anyway this narrows the window even further even if it may not close
>> it completely.
>>
>
> That's my hope too :)
> Otherwise, I'll be (almost) out of ideas how to work this issue around.
>
> Sincerely yours,
> Ivan
>
>