May I ask what inspired this patch? I've seen issues which may have been fixed with this patch and was wondering if you'd seen the same.<br><br>- Mark.<br><br><div><span class="gmail_quote">On 5/27/07, <b class="gmail_sendername">
MythTV</b> <<a href="mailto:mythtv@cvs.mythtv.org">mythtv@cvs.mythtv.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
#3517: Improvements to ProcessRequestThread pool handling in the MainServer of<br>MythBackend<br>--------------------------------------------------------+-------------------<br> Reporter: Russell Bryant <<a href="mailto:russell@russellbryant.net">
russell@russellbryant.net</a>> | Owner: ijr<br> Type: patch | Status: new<br> Priority: minor | Milestone: unknown<br>Component: mythtv | Version: unknown
<br> Severity: medium |<br>--------------------------------------------------------+-------------------<br> The attached patch provides some improvements to the handling of the<br> request processing thread pool in the MainServer of MythBackend.
<br><br> * In the ProcessRequestThread class, both the setup() and killit()<br> functions unlocked the mutex before signalling the wait condition. The<br> patch moves the unlock to be *after* the condition is signalled, to remove
<br> the possibility of a race condition between the thread waiting on the<br> condition and the thread signaling the condition.<br><br> * The rest of the changes rework the way a thread is acquired from the<br> thread pool. I will explain the previous behavior, as well as the
<br> behavior after the patch.<br><br> === Previous Behavior ===<br><br> The code created a timer and checked the container of idle threads once<br> every millisecond, locking and unlocking the mutex each time, until a<br>
thread was acquired. If a thread was not acquired after a total of 10 ms,<br> it would create a new one.<br><br> When creating a new thread, the code would wait 50 ms to attempt to ensure<br> that the new thread is up and running before continuing.
<br><br> === New behavior ===<br><br> The code attempts to retrieve a thread from the thread pool. If one is<br> not available, it uses a thread condition to wait for up to 10 ms until<br> one becomes available. When threads become available, this condition is
<br> signaled to wake up anyone waiting on an idle thread.<br><br> Also, when a ProcessRequestThread is created, it uses a thread condition<br> to wait for the thread to be up and running. This both ensures that the<br> code does wait long enough, and also doesn't wait any longer than it needs
<br> to.<br><br> Also, in the MainServer constructor, it now uses this thread condition to<br> ensure that each thread created for the thread pool is running before<br> moving on. Previously, this check was not done here.
<br><br>--<br>Ticket URL: <<a href="http://svn.mythtv.org/trac/ticket/3517">http://svn.mythtv.org/trac/ticket/3517</a>><br>MythTV <<a href="http://svn.mythtv.org/trac">http://svn.mythtv.org/trac</a>><br>MythTV
<br>_______________________________________________<br>mythtv-commits mailing list<br><a href="mailto:mythtv-commits@mythtv.org">mythtv-commits@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits">
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits</a><br></blockquote></div><br>