<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to patches</title><link>https://sourceforge.net/p/beanstalk/patches/</link><description>Recent changes to patches</description><atom:link href="https://sourceforge.net/p/beanstalk/patches/feed.rss" rel="self"/><language>en</language><lastBuildDate>Tue, 02 Jun 2009 11:19:56 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/beanstalk/patches/feed.rss" rel="self" type="application/rss+xml"/><item><title>reimplemented safe_read_message to fix various bugs</title><link>https://sourceforge.net/p/beanstalk/patches/1/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I have reimplemented safe_read_message to fix various bugs. The original function does a busy-read on a non-blocking socket. Even though the implementation tries to usleep() in between it is still a busy loop. It manages to eat 80% CPU on my AMD quad-core just waiting for reserve() to return a job.&lt;/p&gt;
&lt;p&gt;This new implementation preserves the features of the original and fixes a couple of other bugs. It is implemented with a blocking fread() on the socket so that it does not use too much CPU resources. This makes the old timeout parameter unnecessary. Instead it has a new "recoverable" parameter that helps fixing several possible bugs.&lt;/p&gt;
&lt;p&gt;The original implementation would always reconnect and reissue the last command when an error was encountered. This is not always desirable. When a response from beanstalkd consists of a response and a body of data then BeanQueue uses two calls to safe_read_message(). If the first one succeeds but the second one fails, then when reconnecting the second call would return not the data but the response header again, leading to errors. The new "recoverable" parameter fixes this by not allowing the command to be reissued in such circumstances.&lt;/p&gt;
&lt;p&gt;This new implementation also fixes bug 2729099 and a couple of other errors (e.g. in the old implementation it was possible that $this-&amp;gt;rbuflen did not contain the correct length of $this-&amp;gt;rbuf).&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sander Marechal</dc:creator><pubDate>Tue, 02 Jun 2009 11:19:56 -0000</pubDate><guid>https://sourceforge.net4416f79f0163966a46fb7b0882169922fbbc2111</guid></item></channel></rss>