================ Comment at: source/Plugins/Process/Windows/DebugStatusMonitorThread.cpp:148 @@ +147,3 @@ + // See if any new processes are ready for debug monitoring. + DWORD result = WaitForSingleObject(monitor_thread->m_monitor_event, 1000); + if (result != WAIT_OBJECT_0 && result != WAIT_TIMEOUT) ---------------- scottmg wrote: > Does this mean it'll frequently block for 1s in the middle of debugging? > Seems unfortunate. > > There's only one DebugStatusMonitorThread instance, right? I feel like it > shouldn't be the thread that does the spawning and WaitForDebugEvent. > Instead, it should create subthreads that CreateProcess+WFDE, and send back > to this thread, which can then to a WaitForMultipleObjects on events coming > from the app, and from the child processes being debugged. Yea I felt in the back of my mind that this would have to be revisited at some point, but I also wasn't super happy with the thought of creating 1 thread for each debugged process. I will think about it a little harder, but if I still can't figure out a way to get O(1) number of threads for all processes with true asynchronous multiplexing on both debug events and application message pump events, then the way you propose is probably better than what I have here.
http://reviews.llvm.org/D6037 _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
