Re: thread_test.c problems

wespvp(at)syntegra(dot)com wrote:
> On 4/4/04 11:43 PM, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
>
> > OK, new patch applied that causes all threads to wait until the parent
> > checks their thread-specific pointers. I ran 1000 tests and all passed.
> > Hopefully it will good for you too.
>
> I'll try to give it a test tonight.

Please grab CVS. I added sched_yield() too.

>
> >> Dumb question... Why would you not always use the _r functions if they
> >> exist?
> >
> > Yes, we do use *_r functions in 7.5 if they exist, but in 7.4.X, I think
> > we use the non-R if we can, though we actually just use getaddrinfo() in
> > 7.4.X if it exists. Basically, the threading tests are still in flux,
> > as you can see, in 7.4.X. It works, but it isn't 100% configure perfect
> > yet.
>
> I'm still not clear on this... The thread_test program checks to see if the
> non-r functions are thread safe. If so, it directs you to set xxxx=yes in
> the template file - I assume that causes the non-r function to be used. If
> they are not thread safe, it directs you to use xxxx=no - which I assume
> causes the *_r functions to be used. Why would you not *always* use the _r
> functions if they exist, and only check for thread safety if the _r
> functions do not exist?
>
> Or, am I misunderstanding how the xxx=yes is used?

In 7.4.X, the thought was that if the native function are already
thread-safe, why bother calling the *_r functions, but in 7.5, we
decided it was better to use the *_r functions --- again, 7.4.X has
threads working, but the configure issues were in flux as we learned how
each platform handled threading.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073