Displaying 4 results from an estimated 4 matches for "classllvm_1_1sys_1_1threadlocal".
2014 Dec 12
2
[LLVMdev] why 'const' void * return for ThreadLocalImpl::getInstance()?
I'm probably missing something obvious here, but naively, this makes it kind of awkward to have mutable thread local state...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141212/53b577ae/attachment.html>
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'...
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