Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes:

>  (1) As a part of the process of shutting down worker threads, the code
>      around child.c:1170 currently posts an amount of I/O completion packets
>      equal to the amount of the threads blocked on the I/O completion port.
>      Then it sleeps until all these threads "acknowledge" the completion
>      packets by decrementing the global amount of blocked threads.
>      This can be improved to avoid unnecessary Sleep()'s, and make the
>      shutdown faster.  There is no need to block until the threads actually
>      receive the completion, as the shutdown process includes a separate step
>      that waits until the threads exit.  Instead of synchronizing on the
>      amount of the threads blocked on the I/O completion port, we can send
>      the number of IOCP_SHUTDOWN completion packets equal to the total
>      amount of threads and immediately proceed to the next step.

Committed in https://svn.apache.org/r1801635

>   (2) If the shutdown routine hits a timeout while waiting for the worker
>       threads to exit, it uses TerminateThread() to terminate the remaining
>       threads.
>       Using TerminateThread() can have dangerous consequences such as
>       deadlocks — say, if the the thread is terminated while holding a lock
>       or a heap lock in the middle of HeapAlloc(), as these locks would not
>       be released.  Or it can corrupt the application state and cause a crash.
>       See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686717
>       Presumably, a much better alternative here would be to leave the cleanup
>       to the operating system by calling TerminateProcess().

Committed in https://svn.apache.org/r1801636

>   (3) Assuming (2) is in place, the code around child.c:1170 that waits for
>       multiple thread handles in batches can be simplified.  With (2), there
>       is no difference between ending the wait with one or multiple remaining
>       threads.  (Since we terminate the process if at least one thread is
>       still active when we hit a timeout.)
>       Therefore, instead of making an effort to evenly distribute and batch
>       the handles with WaitForMultipleObjects(), we could just start from
>       one end, and wait for one thread handle at a time.

Committed in https://svn.apache.org/r1801637

Evgeny Kotkov

Reply via email to