[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Universally-unique gensyms

From: Mark H Weaver
Subject: Re: [PATCH] Universally-unique gensyms
Date: Thu, 19 Jan 2012 19:50:55 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Replying to myself...

> David Kastrup <address@hidden> writes:
>> It does not appear to me that there is any locking that would prevent
>> both ending up with the same random value.
> The thread-local 128-bit gensym counters are initialized from
> /dev/urandom.  The kernel ensures that each `read' gets freshly
> generated random bytes, so there's no issue here.  According to
> Wikipedia, this should cover GNU/Linux, OpenBSD, FreeBSD, NetBSD,
> Solaris, Tru64 UNIX, AIX, HP-UX, and MacOS X.
> On platforms without /dev/urandom, I have a fallback that uses the time,
> date, process ID, and a high-resolution timer if available.  In this
> case, depending on the resolution of the timers, it is indeed feasible
> for two threads to end up with the same seed value, which would be bad.
> I think we can solve this problem by including the address of the
> scm_i_thread structure into the fallback seed.

Better yet, I now include two memory addresses in the fallback seed
calculation: an address of a freshly allocated heap cell, and an address
from the local stack frame.  The latter is guaranteed to be different
for different threads, since each thread has its own stack.

This fallback is still not ideal, but it's probably good enough as a
last resort.  Thankfully, almost all systems now have /dev/urandom.
We can add support for additional platform-specific entropy sources as


reply via email to

[Prev in Thread] Current Thread [Next in Thread]