Displaying 3 results from an estimated 3 matches for "randr_r".
Did you mean:
rand_r
2012 Dec 02
1
[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
I don't know if __thread is well-supported enough on compilers to use in
LLVM core code. LLVM has its own support class: ThreadLocal
http://llvm.org/doxygen/classllvm_1_1sys_1_1ThreadLocal.html
And if randr_r() is obsolete, I'm not sure we should be using it. What
platforms have you tested this on? Is it available on Windows, Mac, BSDs?
If not touching global state is important enough, perhaps we should add a
(simple) random number generator to the Support library. I don't think
LLVM would re...
2012 Dec 01
0
[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
Correcting my patch, reg. __thread stuff I'm not very familiar with.
- D.
2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org>
> Agreed, done.
>
> One thing I'm not sure about is this statement in docs:
>
> POSIX.1-2008 marks *rand_r*() as obsolete.
>
> - And... what is the replacement?
>
>
> 2012/12/1 Justin Holewinski <justin.holewinski at
2012 Dec 01
2
[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
Agreed, done.
One thing I'm not sure about is this statement in docs:
POSIX.1-2008 marks *rand_r*() as obsolete.
- And... what is the replacement?
2012/12/1 Justin Holewinski <justin.holewinski at gmail.com>
> If we're keeping the state locally now, perhaps we should store it in a
> per-thread variable. I know rand() isn't thread safe to begin with, but it
> seems