Hello Thomas,
>> 3 . Decide if it's sane for the Windows-based emulation to be in here
>> too, or if it should stay in pgbench.c. Or alternatively, if we're
>> emulating pthread stuff on Windows, why not also put the other pthread
>> emulation stuff from pgbench.c into a "ports" file; that seems
>> premature and overkill for your project. I dunno.
>
> I decided to solve only the macOS problem for now. So in this
> version, the A and B patches are exactly as you had them in your v7,
> except that B includes “port/pg_pthread.h” instead of <pthread.h>.
>
> Maybe it’d make sense to move the Win32 pthread emulation stuff out of
> pgbench.c into src/port too (the pre-existing stuff, and the new
> barrier stuff you added), but that seems like a separate patch, one
> that I’m not best placed to write, and it’s not clear to me that we’ll
> want to be using pthread APIs as our main abstraction if/when thread
> usage increases in the PG source tree anyway. Other opinions welcome.
I think it would be much more consistent to move all the thread complement
stuff there directly: Currently (v8) the windows implementation is in
pgbench and the MacOS implementation in port, which is quite messy.
Attached is a patch set which does that. I cannot test it neither on
Windows nor on MacOS. Path 1 & 2 are really independent.
--
Fabien.
