[PATCH] ntdll: Increase timeout in get_thread_context().

[Paul Gofman]

Fixes hangs during loading or after campaign start in
Mount & Blade II: Bannerlord.

Signed-off-by: Paul Gofman 
---
    The hang happens when NtGetContextThread fails due to time out
    (after successful thread suspend). The timeout happens as the
    thread is busy in read() for regular file called from NtReadFile
    and does not process SIGUSR1 until read is complete. The read()
    may take a real long time when the disk is under heavy load.

dlls/ntdll/unix/thread.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/ntdll/unix/thread.c b/dlls/ntdll/unix/thread.c
index 1a882a99855..a7e2fdef248 100644
--- a/dlls/ntdll/unix/thread.c
+++ b/dlls/ntdll/unix/thread.c
@@ -618,7 +618,7 @@ NTSTATUS get_thread_context( HANDLE handle, context_t *context, unsigned int fla
     if (ret == STATUS_PENDING)
     {
         LARGE_INTEGER timeout;
-        timeout.QuadPart = -1000000;
+        timeout.QuadPart = -5000000;
         if (NtWaitForSingleObject( handle, FALSE, &timeout ))
         {
             NtClose( handle );

[Jacek Caban]

Hi Paul,

On 12.04.2021 20:39, Paul Gofman wrote:
>  The hang happens when NtGetContextThread fails due to time out
>  (after successful thread suspend). The timeout happens as the
>  thread is busy in read() for regular file called from NtReadFile
>  and does not process SIGUSR1 until read is complete. The read()
>  may take a real long time when the disk is under heavy load.

Maybe we should just get rid of the timeout, like we do in 
server_queue_process_apc. It made more sense when we were actively 
retrying to fetch the context.

Thanks,

Jacek

[Paul Gofman]

Hello Jacek,

On 4/12/21 21:45, Jacek Caban wrote:
> Hi Paul,
>
> On 12.04.2021 20:39, Paul Gofman wrote:
> > The hang happens when NtGetContextThread fails due to time out
> >      (after successful thread suspend). The timeout happens as the
> >      thread is busy in read() for regular file called from NtReadFile
> >      and does not process SIGUSR1 until read is complete. The read()
> >      may take a real long time when the disk is under heavy load.
>
> Maybe we should just get rid of the timeout, like we do in
> server_queue_process_apc. It made more sense when we were actively
> retrying to fetch the context.

I am not aware of the scenario when Windows can fail to get the thread
context after a timeout, if you are not aware as well I guess it would
indeed be better to remove it.