On 13.03.2017 21:53, Daniel Lehman wrote:
From 44d603b75fe10d51377c20e4c3c2a1bf031c4fcf Mon Sep 17 00:00:00 2001 From: Daniel Lehman dlehman@esri.com Date: Mon, 12 Dec 2016 16:44:44 -0800 Subject: [PATCH 2/3] msvcrt: Implement Concurrency::event
wait_for_multiple can handle more than WaitForMultipleObjects' limit of 64 a separate thread is used to handle threads that wait on multiple handles and is loosely modeled after wineserver's select request handler a very simple command structure is used to communicate with it over a single shared pipe
Signed-off-by: Daniel Lehman dlehman@esri.com
dlls/msvcrt/lock.c | 387 +++++++++++++++++++++++++++++++++++++++++++++++++-- dlls/msvcrt/main.c | 3 + dlls/msvcrt/msvcrt.h | 18 +++ 3 files changed, 397 insertions(+), 11 deletions(-)
Not sure if its suitable here, but please note that Wines threadpool implementation also supports waiting on more than 64 objects (using similar tricks). If possible, it would be better to avoid the second implementation.
Not sure if its suitable here, but please note that Wines threadpool implementation also supports waiting on more than 64 objects (using similar tricks). If possible, it would be better to avoid the second implementation.
Not sure what you mean. Are you talking about timerqueue_thread_proc?
On 13.03.2017 22:33, Daniel Lehman wrote:
Not sure if its suitable here, but please note that Wines threadpool implementation also supports waiting on more than 64 objects (using similar tricks). If possible, it would be better to avoid the second implementation.
Not sure what you mean. Are you talking about timerqueue_thread_proc?
I'm talking about CreateThreadpoolWait/SetThreadpoolWait or the corresponding ntdll functions TpAllocWait/TpSetWait. Each wait handle would have to be added separately, but there is no limitation for the number of handles. Also see dlls/ntdll/tests/threadpool.c:test_tp_multi_wait for an example how it can be used.
Nevertheless, after more careful reviewing in your patch, it looks like handles are never really exposed to the application, is that correct? I'm not really sure why you need a separate thread then. Why does event_set for example not wake up the the pending waits directly? You have to be careful when locking multiple critical sections, but I do not see any reason why it shouldn't be possible.
Best regards, Sebastian
Nevertheless, after more careful reviewing in your patch, it looks like
handles are never really exposed to the application, is that correct?
correct
I'm not really sure why you need a separate thread then. Why does event_set for
example not wake up the the pending waits directly? You have to be careful when locking multiple critical sections, but I do not see any reason why it shouldn't be possible.
i'll send one without
-
Daniel Lehman -
Sebastian Lackner