On Sun, Jan 31, 2021 at 1:18 AM Fabien COELHO <coe...@cri.ensmp.fr> wrote: > 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.
Hmm. Well this is totally subjective, but here's how I see this after thinking about it a bit more: macOS does actually have POSIX threads, except for this tiny missing piece, so it's OK to write a toy implementation that is reasonably conformant, and put it in there using the usual AC_REPLACE_FUNCS machinery. It will go away when Apple eventually adds a real one. Windows does not, and here we're writing a very partial toy implementation that is far from conformant. I think that's OK for pgbench's purposes, for now, but I'd prefer to keep it inside pgbench.c. I think at some point in the (hopefully not too distant) future, we'll start working on thread support for the backend, and then I think we'll probably come up with our own abstraction over Windows and POSIX threads, rather than trying to use POSIX API wrappers from Windows, so I don't really want this stuff in the port library. Does this make some kind of sense? > Attached is a patch set which does that. I cannot test it neither on > Windows nor on MacOS. Path 1 & 2 are really independent. No worries. For some reason I have a lot of computers; I'll try to get this (or rather a version with the Windows stuff moved back) passing on all of them soon, with the aim of making it committable.
