pgsql: Invent a variant of getopt(3) that is thread-safe - Mailing list pgsql-committers

From Heikki Linnakangas
Subject pgsql: Invent a variant of getopt(3) that is thread-safe
Date
Msg-id E1w7Gkr-002BNj-1M@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Invent a variant of getopt(3) that is thread-safe

The standard getopt(3) function is not re-entrant nor thread-safe.
That's OK for current usage, but it's one more little thing we need to
change in order to make the server multi-threaded.

There's no standard getopt_r() function on any platform, I presume
because command line arguments are usually parsed early when you start
a program, before launching any threads, so there isn't much need for
it. However, we call it at backend startup to parse options from the
startup packet. Because there's no standard, we're free to define our
own.

The pg_getopt_start/next() implementation is based on the old getopt
implementation, I just gathered all the state variables to a struct.
The non-re-entrant getopt() function is now a wrapper around the
re-entrant variant, on platforms that don't have getopt(3).
getopt_long() is not used in the server, so we don't need to provide a
re-entrant variant of that.

Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
Discussion: https://www.postgresql.org/message-id/d1da5f0e-0d68-47c9-a882-eb22f462752f@iki.fi

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/fd8e3f7ceeed8b0155e124a0da4ec6a4fb53ec1f

Modified Files
--------------
src/include/port/pg_getopt_ctx.h |  39 +++++++++++
src/port/Makefile                |   1 +
src/port/getopt.c                |  91 ++++++--------------------
src/port/meson.build             |   1 +
src/port/pg_getopt_ctx.c         | 136 +++++++++++++++++++++++++++++++++++++++
src/tools/pgindent/typedefs.list |   1 +
6 files changed, 199 insertions(+), 70 deletions(-)


pgsql-committers by date:

Previous
From: Melanie Plageman
Date:
Subject: pgsql: Pass down information on table modification to scan nodes
Next
From: Tom Lane
Date:
Subject: pgsql: Be more careful to preserve consistency of a tuplestore.