Re: Release date for Privoxy 3.0.24

--===============4134529441398133223==
Content-Type: multipart/signed; micalg=pgp-sha256;
	boundary="Sig_/BkkevVpLrMA/Mqath.b7X5+";
	protocol="application/pgp-signature"

--Sig_/BkkevVpLrMA/Mqath.b7X5+
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Ian Silvester <[email protected]> wrote:

> On 2016-01-21 11:46, Fabian Keil wrote:
> > Ian Silvester <[email protected]> wrote:
> > =20
> >> 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. =20
> > 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. =20
> Unless you know more than what is said in the comment,  I read it to say=
=20
> that the issue has only been shown to affect OS X, but probably affects=20
> other OSes that use the MACH kernel.
>=20
> Are you certain that collisions could occur as-is? It seems a remote=20
> possibility to me.

Unless I miss something, after the "% 1000" there can't be more than
1000 unique values left and as a result there must be collisions if
there are more than 1000 different threads ids.

In practice the number of required threads to get collisions is probably
a lot lower, as the thread ids aren't assigned randomly or by incrementing
the previous thread id by one.

I suspect that the only guarantee is that two threads that are running
at the same time have different thread ids.

> If you are sure, perhaps rather than add the better hashing to our=20
> already insanely long TODO list I simply remove the labs function call?=20

The change from abs() to labs() should have no affect on the collision
"risk".

BTW, it seems like we may be able to solve the issue by using
pthread_getthreadid_np() instead of pthread_self() in the future.

> This would leave us with guaranteed-unique 9 byte long thread ids=20
> resulting from having their rightmost three 0s trimmed.

I don't think so.

>                                                         These may still=20
> not be unique in their first 4 bytes (though they're significantly more=20
> different than the raw ids); I'll admit I don't understand the comment's=
=20
> talk of a "debuggable value in the first 4 bytes" - do you think it=20
> simply means a unique value in those 4 bytes? And what is so important=20
> about the first 4 bytes of the value from a debugging perspective?

While I'm having trouble parsing the comment as well, I interpret it simila=
rly.
I assume David meant to write "discernible" or "distinguishable" or somethi=
ng
like this and was using a 32 bit system which is relevant for the "4 bytes"=
 part.

Fabian

--Sig_/BkkevVpLrMA/Mqath.b7X5+
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWoSfuAAoJEGkYIpGLojccPQ0P/j/EeTIDQPjJQMRtTN41MrKu
GisYiZJkjCd5eXcrj7+xlBlYRXZbZQu/gRk/9aEyz6U3fy6ujPViHfa2bFsdQp3F
OESSi0nqqrou0UN5ka4uPmY8QxO/fTZ20xt6STVgJFt/Z6qgseHtgTdryuwwXvh0
2UUnu7MTR0dG7eN+MrE2ccvFRn5qAw/+hAPA8C6vvBMk/SM0YNV5LUggJyjsNpgs
6AlPegWRXQA3MV/J+H6pYMdoe13jurLTxJoQTja7+nI85JJTxZ5P/X4krKm19EQ6
8YNByEfmXsorKSxQr+w/vYMBS/Pnh+tgPNaWpD6dXihvrsMvZsaoc7GXGGDmU/py
llY64LQZbCjPzGk0q95oQHBYKJi68PbvcelmLPVC2qNbKCypd8lL7x8jrjbNI6jZ
eSfuFq43QWrreCMUd+OcRGKsWog9o8JaT3KYaFXnmxkoIMAWItpKMMOD1F8E/3JI
ncuvBM7ahCFeho+a1hWozrdMHB6mjpXxVAgJsRwP/asUT9Io1Epgrk3ztYz7wO9b
7T8egqdNwpwxOUnLPQqALxoP+kHHZydjLq9IJ9/G7a7H82QlRkLN7Ap6hFbNDWfx
2xEYTmROVU5/Sq5JaaA3tatQHmzpkDbGXnwXmzT1a00CX7iVOSLitBvsTRgU9zBC
rHnZdJPTodz6JhpuiDi8
=XZ4L
-----END PGP SIGNATURE-----

--Sig_/BkkevVpLrMA/Mqath.b7X5+--


--===============4134529441398133223==
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
--===============4134529441398133223==
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

--===============4134529441398133223==--