Howdy, we've discovered that windows seems to not allow suspended threads to acquire synchronization objects, which make really really good sense, while wine does. I've attached a simple test case, the code for the test case and a ReWind licensed patch for the problem. Would people have a look at the patch and let me know if it's the best way to fix it, or if I've missed anything? (other than the attachements on the first go at this)?
Thanks, Peter peter@transgaming.com
Index: server/thread.c =================================================================== RCS file: /home/wine/wine/server/thread.c,v retrieving revision 1.87 diff -u -r1.87 thread.c --- server/thread.c 1 Feb 2003 01:38:40 -0000 1.87 +++ server/thread.c 13 Feb 2003 21:59:25 -0000 @@ -401,6 +401,9 @@ struct thread_wait *wait = thread->wait; struct wait_queue_entry *entry = wait->queues;
+ /* Suspended threads may not acquire locks */ + if( thread->suspend > 0 ) return -1; + assert( wait ); if (wait->flags & SELECT_ALL) { @@ -938,7 +941,10 @@ if ((thread = get_thread_from_handle( req->handle, THREAD_SUSPEND_RESUME ))) { if (thread->state == TERMINATED) set_error( STATUS_ACCESS_DENIED ); - else reply->count = resume_thread( thread ); + else { + reply->count = resume_thread( thread ); + if( reply->count == 1 ) wake_thread( thread ); + } release_object( thread ); } }
Peter Hunnisett peter@transgaming.com writes:
we've discovered that windows seems to not allow suspended threads to acquire synchronization objects, which make really really good sense, while wine does. I've attached a simple test case, the code for the test case and a ReWind licensed patch for the problem. Would people have a look at the patch and let me know if it's the best way to fix it, or if I've missed anything? (other than the attachements on the first go at this)?
I think the patch looks reasonable, though you probably want to handle the case of a suspended process too.