Replying to myself...
> David Kastrup 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
Hi!
Mark H Weaver skribis:
> Anyway, here's the new patch. What do you think? Okay to push? :)
OK to push. Thank you!
Ludo’.
David Kastrup 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
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> Andy Wingo writes:
>>>
Sorry for asking a stupid question, but why is it that we want the
gensym counter to be thread-local? Just to avoid the mutex? TBH I
don't think it's that big of a point of c
David Kastrup writes:
> Mark H Weaver writes:
>
>> Andy Wingo writes:
>>
>>> Sorry for asking a stupid question, but why is it that we want the
>>> gensym counter to be thread-local? Just to avoid the mutex? TBH I
>>> don't think it's that big of a point of contention. This risks
>>> devolut
Mark H Weaver writes:
> Andy Wingo writes:
>
>> Sorry for asking a stupid question, but why is it that we want the
>> gensym counter to be thread-local? Just to avoid the mutex? TBH I
>> don't think it's that big of a point of contention. This risks
>> devolution into bike-shed-landia tho...
Hi Ludovic,
Thanks for the review! Attached below are updated patches, which I
believe incorporate all of your suggestions.
> This looks cool, though I must confess I don’t see why sizeof (int) is
> not enough for everyone, nor whether this warrants adding all this code.
For some applications,
Andy Wingo writes:
> Sorry for asking a stupid question, but why is it that we want the
> gensym counter to be thread-local? Just to avoid the mutex? TBH I
> don't think it's that big of a point of contention. This risks
> devolution into bike-shed-landia tho...
It's a reasonable question. I
Andy Wingo skribis:
> On Wed 18 Jan 2012 22:41, l...@gnu.org (Ludovic Courtès) writes:
>
>> Could you stick to GNU-style change logs, describing the change (for
>> example, “New function”), and not the rationale, function, etc.?
>>
>> (Andy might disagree with me, but don’t listen to him. ;-))
>
On Wed 18 Jan 2012 22:41, l...@gnu.org (Ludovic Courtès) writes:
> Could you stick to GNU-style change logs, describing the change (for
> example, “New function”), and not the rationale, function, etc.?
>
> (Andy might disagree with me, but don’t listen to him. ;-))
FWIW I have grown to agree wit
Hi Mark,
Mark H Weaver skribis:
> Here's an improved implementation, incorporating your excellent feedback
> and also implementing thread-local gensym counters, thus eliminating the
> mutex altogether. What do you think?
This looks cool, though I must confess I don’t see why sizeof (int) is
no
Oh, and they are (still) statistically unique, not “universally-unique.”
Ludo’.
I wrote:
> + /* This is the first time gensym has been called in this thread.
> + Allocate and randomize our new thread-local gensym counter */
> + digit_buf = (unsigned char *) scm_malloc (GENSYM_LENGTH);
Oops, that should be `scm_gc_malloc_pointerless'.
Mark
Hi Andy,
Here's an improved implementation, incorporating your excellent feedback
and also implementing thread-local gensym counters, thus eliminating the
mutex altogether. What do you think?
Thanks!
Mark
>From 9090dfeb58846d637150f5f88e344c7d980efdf2 Mon Sep 17 00:00:00 2001
From: Mar
On Tue 17 Jan 2012 14:57, Andy Wingo writes:
> I think the lazy initialization needs to happen within the lock. Also
> it would be nice to factor out the initialization of the random seed
> would be a nice helper to have in random.[ch].
Sigh, mind racing ahead of the fingers:
"Also it would
Hi Mark,
Excellent!
On Tue 17 Jan 2012 14:27, Mark H Weaver writes:
> This patch makes our gensyms universally-unique. Comments welcome.
I think the lazy initialization needs to happen within the lock. Also
it would be nice to factor out the initialization of the random seed
would be a nice
This patch makes our gensyms universally-unique. Comments welcome.
Mark
>From 18616afc6a3d5aca48da2e0819d08d7ff98de214 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 17 Jan 2012 08:15:10 -0500
Subject: [PATCH] Universally-unique gensyms
* libguile/symbols.c (scm_gensym):
17 matches
Mail list logo
