From: | Lee Kindness <lkindness(at)csl(dot)co(dot)uk> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Kurt Roeckx <Q(at)ping(dot)be>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Larry Rosenman <ler(at)lerctr(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Lee Kindness <lkindness(at)csl(dot)co(dot)uk> |
Subject: | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Date: | 2003-09-01 17:26:17 |
Message-ID: | 16211.33081.318922.652203@kelvin.csl.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Guys, too much thought is being spent on this...
1. For the _r functions we "need" we should ALWAYS use them if the
system we are building on has them - they WILL be thread-safe.
2. If the system is missing a _r function then we implement a wrapper
to call the normal non-_r version. However we do NOT make this wrapper
call thread-safe - we assume the non-_r version already is.
Together both steps ensure the code calling the _r function is
readable (just one function signature) and that libpq will be
thread-safe if the system C library is thread-safe. So this will catch
all modern UNIX OSs.
We really don't want to go deeper than this - of we do so we're
wasting time on odd-ball systems that aren't thread-safe anyway - so
for them libpq's thread-safety is of no consequence.
L.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2003-09-01 17:39:06 | Re: array constructor can't construct empty array |
Previous Message | Larry Rosenman | 2003-09-01 17:25:36 | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |