Robert Haas <robertmh...@gmail.com> writes:
> On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> If I'm reading the code right, it only modifies __libc_drand48_data on
>> first call, so as long as we called erand48() at least once before
>> spawning the child threads, it would probably work. That seems pretty
>> fragile in the face of the fact that they explicitly state that
>> they're modifying the global random generator state and that you
>> should use erand48_r() if you want reentrant behavior. So I think if
>> we're going to go the erand48() route we probably ought to force
>> pgbench to always use our version rather than any OS-supplied version.
> Attached is a try at that approach.
I don't find this to be a particularly safe idea:
> #ifndef HAVE_ERAND48
> -/* we assume all of these are present or missing together */
> -extern double erand48(unsigned short xseed[3]);
> -extern long lrand48(void);
> -extern void srand48(long seed);
> +#define erand48(x) pg_erand48(x)
> +#define lrand48() pg_lrand48()
> +#define srand48(x) pg_srand48(x)
> #endif
See our recent trials with python headers for an example of why this
might cause problems on some platforms. For that matter, I believe
<stdlib.h> would be within its rights to be defining these names as
macros already.
If you want erand48_r, best to provide that API, not kluge up some
other functions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
