Hello Tom,
>> My question is: would someone still object strongly to the removal of this
>> "thread fork emulation" hack in pgbench?
>
> By my count, the pthread-emulation code amounts to about 175 lines out of
> the nearly 4000 in pgbench.c. That's not an undue burden IMO (it's not,
> for comparison's sake, very much more than the amount of WIN32-specific
> code in that file).
From my point of view, the burden is how things can be implemented if you
have to assume "no threads".
In the discussion at hand which motivates this renewed request, the
question is whether external merge sorts implying rescanning and
reprinting files over and over should be implemented in pgbench so as to
recombine log files.
Now if we have threads, it is simpler (if the overhead is reasonable) that
threads share a file handle and just generate one file, so there is no
merging. That is not possible with processes at least for the aggregated
logs because the thread data must be combined, or would require that
pgbench use shared memory and so on, but then it is really a lot of bother
for a limited feature.
The alternative is that the feature would not be available if no thread,
but then people object to that, on principle.
> And what will you do instead? It would be fine I think for pgbench to
> not allow --jobs different from 1 on a threadless platform, but not for
> it to fail to work altogether.
Sure. No thread really means working with only one thread.
> It looks to me like allowing it to compile without that code would take
> nearly as much effort/mess as what's there now.
My motivation is to simplify how things are done by simply assuming that
threads are available and can share data, esp for counters.
>> So the underlying question is, does Tom and Robert's opinion have changed
>> from 2 years ago?
>
> Not mine.
Ok! I'll ask again in 2017, and probably again in 2019:-)
--
Fabien.