Re: Release date for Privoxy 3.0.24
Ian Silvester <[email protected]> Thu, 21 Jan 2016 12:24:05 -0500
| Newsgroups | gmane.comp.web.privoxy.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============4424195679258940370== Content-Type: multipart/alternative; boundary="------------060108090306030105000704" This is a multi-part message in MIME format. --------------060108090306030105000704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2016-01-21 11:46, Fabian Keil wrote: > Ian Silvester <[email protected]> wrote: > >> I have tested removal of the get_thread_id MACH IFDEF. It is indeed >> strictly unnecessary since even without it the threads are still >> uniquely identified. I propose however that it is kept and modified as >> per the compiler warning, since the raw IDs use four extra bytes which >> could better be used by the remainder of the log line, plus the comment >> in the code is strictly true. >> >> Let me know if anyone disagrees. > I don't disagree with your labs() commit which seems to be > the best solution before the release. > > My main objection to the MACH section in general is that > "this_thread % 1000" actually increases the chances of id > collisions and that it's only done on MACH while the issue > it's supposed to address exists on other platforms as well. > > Eventually it may make sense to figure out a hashing scheme > that works cross-platform and is less likely to cause collisions. Unless you know more than what is said in the comment, I read it to say that the issue has only been shown to affect OS X, but probably affects other OSes that use the MACH kernel. Are you certain that collisions could occur as-is? It seems a remote possibility to me. If you are sure, perhaps rather than add the better hashing to our already insanely long TODO list I simply remove the labs function call? This would leave us with guaranteed-unique 9 byte long thread ids resulting from having their rightmost three 0s trimmed. These may still not be unique in their first 4 bytes (though they're significantly more different than the raw ids); I'll admit I don't understand the comment's talk of a "debuggable value in the first 4 bytes" - do you think it simply means a unique value in those 4 bytes? And what is so important about the first 4 bytes of the value from a debugging perspective? Ian -- My PGP public key <http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc>. --------------060108090306030105000704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 2016-01-21 11:46, Fabian Keil wrote:<br> <blockquote cite="mid:[email protected]" type="cite"> <pre wrap="">Ian Silvester <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">I have tested removal of the get_thread_id MACH IFDEF. It is indeed strictly unnecessary since even without it the threads are still uniquely identified. I propose however that it is kept and modified as per the compiler warning, since the raw IDs use four extra bytes which could better be used by the remainder of the log line, plus the comment in the code is strictly true. Let me know if anyone disagrees. </pre> </blockquote> <pre wrap=""> I don't disagree with your labs() commit which seems to be the best solution before the release. My main objection to the MACH section in general is that "this_thread % 1000" actually increases the chances of id collisions and that it's only done on MACH while the issue it's supposed to address exists on other platforms as well. Eventually it may make sense to figure out a hashing scheme that works cross-platform and is less likely to cause collisions.</pre> </blockquote> Unless you know more than what is said in the comment, I read it to say that the issue has only been shown to affect OS X, but probably affects other OSes that use the MACH kernel.<br> <br> Are you certain that collisions could occur as-is? It seems a remote possibility to me.<br> <br> If you are sure, perhaps rather than add the better hashing to our already insanely long TODO list I simply remove the labs function call? This would leave us with guaranteed-unique 9 byte long thread ids resulting from having their rightmost three 0s trimmed. These may still not be unique in their first 4 bytes (though they're significantly more different than the raw ids); I'll admit I don't understand the comment's talk of a "debuggable value in the first 4 bytes" - do you think it simply means a unique value in those 4 bytes? And what is so important about the first 4 bytes of the value from a debugging perspective?<br> <br> Ian<br> <br> <div class="moz-signature">-- <br> <a href="http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc">My PGP public key</a>.</div> </body> </html> --------------060108090306030105000704-- --===============4424195679258940370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 --===============4424195679258940370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ijbswa-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ijbswa-developers --===============4424195679258940370==--