Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)

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.

In response to

Responses

Browse pgsql-hackers by date

  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 ...)