Hello Thomas,
I must say that I'm not a big fan of the macro-based all-in-capitals API
for threads because it exposes some platform specific uglyness (eg
THREAD_FUNC_CC) and it does not look much like clean C code when used. I
liked the previous partial pthread implementation better, even if it was
not the real thing, obviously.
But we were using macros already, to support --disable-thread-safety
builds.
Yep, but the look and feel was still C code.
I just changed them to upper case and dropped the 'p', because I didn't
like to pretend to do POSIX threads, but do it so badly.
Hmmm. From the source code point of view it was just like actually using
posix threads, even if the underlying machinery was not quite that on some
systems. I value looking at "beautiful" and "standard" code if possible,
even if there is some cheating involved, compared to exposing macros. I
made some effort to remove the pretty ugly and inefficient INSTR_TIME
macros from pgbench, replaced with straightforward arithmetic and inlined
functions. Now some other macros just crept back in:-) Anyway, this is
just "les goûts et les couleurs" (just a matter of taste), as we say here.
Perhaps we should drop --disable-thread-safety soon, and perhaps it is
nearly time to create a good thread abstraction in clean C code, for use
in the server and here? Then we won't need any ugly macros.
+1.
ISTM that with the current approach threads are always used on Windows,
i.e. pgbench does not comply to "ENABLE_THREAD_SAFETY" configuration on
that platform. Not sure whether this is an issue that need to be
addressed, though.
The idea of that option, as I understand it, is that in ancient times
there were Unix systems with no threads (that's of course the reason
PostgreSQL is the way it is). I don't think that was ever the case
for Windows NT, and we have no build option for that on Windows
AFAICS.
Ok, fine with me.
--
Fabien.
