This is probably what's also exposed via Math.random()?  I don't know
what guarantees we want there, but there have been complaints about
JavaScript random not being strong enough.  I would try to do
something a little bit fancier than LFSR.  I don't know what the
proper balance is between simple and randomy, Mersenne Twister seems
to be what everyone usually uses...

On Wed, Apr 29, 2009 at 6:58 PM, Ivan Posva <[email protected]> wrote:
> In short we should have a quick non-crypto safe random number
> generator in OS::Random(). That would also solve the multi-threading
> issue because V8 is not multi-threaded. I will provide one later this
> week.
>
> Cheers,
> -Ivan
>
>
> On Wed, Apr 29, 2009 at 09:51, Dean McNamee <[email protected]> wrote:
>> We solved this for base/rand_util*, although the implementation is
>> more "secure" meaning slow.  I am not sure how much of a threat is
>> with random(), because I imagine all implementations actually do hold
>> locks, but it's not specified that way...
>>
>> On Wed, Apr 29, 2009 at 6:47 PM,  <[email protected]> wrote:
>>> On 2009/04/29 09:14:52, Dean McNamee wrote:
>>>>
>>>> Just to be annoying, we probably shouldn't be using random() (it's not
>>>
>>> thread
>>>>
>>>> safe, etc).
>>>
>>> Do you have a suggestion on what we should use instead? (Know of a good
>>> open source & license-compatible replacement?)
>>>
>>>
>>> http://codereview.chromium.org/100147
>>>
>>
>

--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to