random, srandom, and initstate
Jeff Johnston
jjohnstn@redhat.com
Tue Jun 1 08:35:00 GMT 2010
On 05/31/2010 05:01 AM, Corinna Vinschen wrote:
> On May 31 10:36, Corinna Vinschen wrote:
>> On May 19 13:40, Joel Sherrill wrote:
>>> (2) Should I go ahead and modify them to be
>>> the _r versions and have the non-_r version
>>> call those with static variables?
>>
>> Yes. [...]
>
> Or, maybe not. Full reentrancy would require to have not only a couple
> of additional scalar variables in reent, but also to keep the randtbl
> array reentrant. That's kind of a lot of stuff.
>
> Jeff, what do you think?
>
Assuming we are talking about the glibc _r versions which take a struct
random_data pointer...
The _r routines will use the struct. AFAICT, the state pointer points
to an allocated array so modifying the data is ok.
The reent struct should have the struct added. It will need allocation
and initialization for small reent platforms. The non _r routines will
call the _r routines and pass the struct random_data pointer from
_REENT. There should be no static data.
Using the _REENT struct will make it so that automatic reentrancy will
just work using the __getreent system in libc/include/sys/reent.h (i.e.
each thread will get/use its own struct random_data under the covers).
Make sense?
-- Jeff J.
>
> Corinna
>
More information about the Newlib
mailing list