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

[Daniel D. Daugherty]

On 10/29/14 4:56 AM, 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/

src/os/windows/vm/os_windows.cpp
     No comments.

Thumbs up! Thanks for adding more comments.

Dan




>
>>
>>>>
>>>
>>> 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
>
>