pgsql: pgbench: Refactor thread portability support.
pgbench: Refactor thread portability support.
Instead of maintaining an incomplete emulation of POSIX threads for
Windows, let's use an extremely minimalist macro-based abstraction for
now. A later patch will extend this, without the need to supply more
complicated pthread emulation code. (There may be a need for a more
serious portable thread abstraction in later projects, but this is not
it.)
Minor incidental problems fixed: it wasn't OK to use (pthread_t) 0 as a
special value, it wasn't OK to compare thread_t values with ==, and we
incorrectly assumed that pthread functions set errno.
Discussion: /messages/by-id/20200227180100.zyvjwzcpiokfsqm2@alap3.anarazel.de
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/b1d6a8f86813772b9198367a34c8ff8bff7fef9e
Modified Files
--------------
src/bin/pgbench/pgbench.c | 126 ++++++++++++----------------------------------
1 file changed, 31 insertions(+), 95 deletions(-)
Hi Thomas,
On Wed, Mar 10, 2021 at 04:52:01AM +0000, Thomas Munro wrote:
pgbench: Refactor thread portability support.
Instead of maintaining an incomplete emulation of POSIX threads for
Windows, let's use an extremely minimalist macro-based abstraction for
now. A later patch will extend this, without the need to supply more
complicated pthread emulation code. (There may be a need for a more
serious portable thread abstraction in later projects, but this is not
it.)
This one is causing a failure in whelk:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=whelk&dt=2021-03-10%2006%3A41%3A53
src/bin/pgbench/pgbench.c(6154): warning C4024: '_beginthreadex' :
different types for formal and actual parameter 3 [C:\\buildfarm\\buildenv\\HEAD\\pgsql.build\\pgbench.vcxproj]
--
Michael
On Wed, Mar 10, 2021 at 8:10 PM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Mar 10, 2021 at 04:52:01AM +0000, Thomas Munro wrote:
pgbench: Refactor thread portability support.
Instead of maintaining an incomplete emulation of POSIX threads for
Windows, let's use an extremely minimalist macro-based abstraction for
now. A later patch will extend this, without the need to supply more
complicated pthread emulation code. (There may be a need for a more
serious portable thread abstraction in later projects, but this is not
it.)This one is causing a failure in whelk:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=whelk&dt=2021-03-10%2006%3A41%3A53
src/bin/pgbench/pgbench.c(6154): warning C4024: '_beginthreadex' :
different types for formal and actual parameter 3 [C:\\buildfarm\\buildenv\\HEAD\\pgsql.build\\pgbench.vcxproj]
Thanks, looking at this and the others.
On Wed, Mar 10, 2021 at 8:14 PM Thomas Munro <thomas.munro@gmail.com> wrote:
On Wed, Mar 10, 2021 at 8:10 PM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Mar 10, 2021 at 04:52:01AM +0000, Thomas Munro wrote:
pgbench: Refactor thread portability support.
Instead of maintaining an incomplete emulation of POSIX threads for
Windows, let's use an extremely minimalist macro-based abstraction for
now. A later patch will extend this, without the need to supply more
complicated pthread emulation code. (There may be a need for a more
serious portable thread abstraction in later projects, but this is not
it.)This one is causing a failure in whelk:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=whelk&dt=2021-03-10%2006%3A41%3A53
src/bin/pgbench/pgbench.c(6154): warning C4024: '_beginthreadex' :
different types for formal and actual parameter 3 [C:\\buildfarm\\buildenv\\HEAD\\pgsql.build\\pgbench.vcxproj]Thanks, looking at this and the others.
whelk is complaining about a missing __stdcall (not clear why various
other Windows systems in CI, real life and the BF didn't mind, but I
have an attempt at a fix ready to push soon). lapwing is just a silly
%ld where INT64_FORMAT was wanted, repro'd and fixed here in a -m32
build. I'm now contemplating what's up with hoverfly (some AIX header
problem)...
On Wed, Mar 10, 2021 at 8:51 PM Thomas Munro <thomas.munro@gmail.com> wrote:
... I'm now contemplating what's up with hoverfly (some AIX header
problem)...
Pushed something for the other two failures seen, but for this one I'm
temporarily stumped. We managed to compile all kinds of stuff that
surely includes the modified header, and then we get to plpython and
we show an error that implies that HAVE_CLOCK_GETTIME is defined and
that we included <time.h>, and yet the compiler has never heard of
clock_gettime(). It's like someone clobbered someone's include
guards, or something of that level of murkiness. Thinking.
On Wed, Mar 10, 2021 at 9:38 PM Thomas Munro <thomas.munro@gmail.com> wrote:
On Wed, Mar 10, 2021 at 8:51 PM Thomas Munro <thomas.munro@gmail.com> wrote:
... I'm now contemplating what's up with hoverfly (some AIX header
problem)...Pushed something for the other two failures seen, but for this one I'm
temporarily stumped. We managed to compile all kinds of stuff that
surely includes the modified header, and then we get to plpython and
we show an error that implies that HAVE_CLOCK_GETTIME is defined and
that we included <time.h>, and yet the compiler has never heard of
clock_gettime(). It's like someone clobbered someone's include
guards, or something of that level of murkiness. Thinking.
Hrrmph. src/pl/plpython/plpython.h's use of #undef _POSIX_C_SOURCE
looks a bit suspicious.
On Wed, Mar 10, 2021 at 9:49 PM Thomas Munro <thomas.munro@gmail.com> wrote:
On Wed, Mar 10, 2021 at 9:38 PM Thomas Munro <thomas.munro@gmail.com> wrote:
On Wed, Mar 10, 2021 at 8:51 PM Thomas Munro <thomas.munro@gmail.com> wrote:
... I'm now contemplating what's up with hoverfly (some AIX header
problem)...Pushed something for the other two failures seen, but for this one I'm
temporarily stumped. We managed to compile all kinds of stuff that
surely includes the modified header, and then we get to plpython and
we show an error that implies that HAVE_CLOCK_GETTIME is defined and
that we included <time.h>, and yet the compiler has never heard of
clock_gettime(). It's like someone clobbered someone's include
guards, or something of that level of murkiness. Thinking.Hrrmph. src/pl/plpython/plpython.h's use of #undef _POSIX_C_SOURCE
looks a bit suspicious.
Fix pushed.