This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: random, srandom, and initstate
Hi Joern,
On Mar 27 20:46, Joern Rennecke wrote:
> Quoting Joern Rennecke <amylaar@spamcop.net>:
>
> >Hmm, locking would seriously reduce the class of multithreading scenarious
> >where random can work. If an interrupt tried to use it while it is already
> >active, deadlock would result - similar to malloc.
> >OTOH it should avoid all the issues in having to change our data structures
> >to support random (3) reentrancy - allowing us to use the NetBSD version
> >with just minor changes.
> >And it should be good enough for gcc.c-torture/unsorted/udivmod4.c and
> >its ilk.
>
> I've tried an implementation; tested on x86_64-unknown-linux-gnu X sh-elf
> with gcc/testsuite/gcc.dg/vshift-{1,3}.c rolled back to revision 181613 .
>
> Below is the diff to the NetBSD original, and the second attachment is the
> patch for newlib.
>
> I'm not sure about random_r / srandom_r : should I add a dummy struct _reent *
> parameter so that the implementation could later/optionally be changed to
> work without locking?
I think this would make sense, even if only for symmetry with the
other reentrant functions.
As for your patch:
- It's missing the declarations in stdlib.h (guarded with __STRICT_ANSI__).
- Why does srandom_r take an unsigned long parameter while srandom
only takes unsigned int?
Otherwise it looks good.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat