You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if ( !m_bExecOnThreadPoolThreadsOnly && m_SharedQueue.Pop( &pJob ) )
619
+
{
620
+
ServiceJobAndRelease( pJob );
621
+
m_nJobs--;
622
+
}
623
+
#if1
624
+
else
625
+
{
626
+
// If we can't process jobs or there are no jobs to process, stop trying to respond to them.
627
+
break;
628
+
}
629
+
#else
630
+
else
631
+
{
632
+
// UNDONE(mastercoms): we can just use TT_INFINITE as needed?
633
+
634
+
// Since there are no jobs for the main thread set the timeout to infinite.
635
+
// The only disadvantage to this is that if a job thread creates a new job
636
+
// then the main thread will not be available to pick it up, but if that
637
+
// is a problem you can just create more worker threads. Debugging test runs
638
+
// of TF2 suggests that jobs are only ever added from the main thread which
639
+
// means that there is no disadvantage.
640
+
// Waiting on the events instead of busy spinning has multiple advantages.
641
+
// It avoids wasting CPU time/electricity, it makes it more obvious in profiles
642
+
// when the main thread is idle versus busy, and it allows ready thread analysis
643
+
// in xperf to find out what woke up a waiting thread.
644
+
// It also avoids unnecessary CPU starvation -- seen on customer traces of TF2.
645
+
timeout = TT_INFINITE;
646
+
}
647
+
#endif
613
648
}
614
-
else
649
+
650
+
// Now that we have responded to jobs with near zero latency, and there's no more jobs to process, enter our extended wait with timeout if we do need to wait more.
651
+
if (result == WAIT_TIMEOUT)
615
652
{
616
-
// Since there are no jobs for the main thread set the timeout to infinite.
617
-
// The only disadvantage to this is that if a job thread creates a new job
618
-
// then the main thread will not be available to pick it up, but if that
619
-
// is a problem you can just create more worker threads. Debugging test runs
620
-
// of TF2 suggests that jobs are only ever added from the main thread which
621
-
// means that there is no disadvantage.
622
-
// Waiting on the events instead of busy spinning has multiple advantages.
623
-
// It avoids wasting CPU time/electricity, it makes it more obvious in profiles
624
-
// when the main thread is idle versus busy, and it allows ready thread analysis
625
-
// in xperf to find out what woke up a waiting thread.
626
-
// It also avoids unnecessary CPU starvation -- seen on customer traces of TF2.
627
-
timeout = TT_INFINITE;
653
+
result = ThreadWaitForEvents( nEvents, pEvents, bWaitAll, timeout );
628
654
}
629
655
}
656
+
else
657
+
{
658
+
// We explicitly asked for it, so trust that we have a good reason.
659
+
result = ThreadWaitForEvents( nEvents, pEvents, bWaitAll, 0 );
0 commit comments