Dear Robert,
>> Here is a v4 that takes into account most of your points: The report is
>> performed for all threads by thread 0, however --progress is not supported
>> under thread fork emulation if there are more than one thread. The report
>> time does not slip anymore.
>
> I don't believe that to be an acceptable restriction.
The "pthread fork emulation" is just an ugly hack to run pgbench on a host
that does not have pthreads (portable threads). I'm not sure that it
applies on any significant system, but I can assure you that it imposes
severe limitations about how to do things properly in pgbench: As there is
no threads, there is no shared memory, no locking mecanism, nothing
really. So it is hard to generated a shared report in such conditions.
My first proposal is to remove the fork emulation altogether, which would
remove many artificial limitations to pgbench and simplify the code
significantly. That would be an improvement.
Otherwise, he simplest possible adaptation, if it is required to have the
progress feature under fork emulation to pass it, is that under "fork
emulation" each processus reports its current progress instead of having a
collective summing.
Note that it is possible to implement the feature with interprocess
communications, but really generating many pipes will add a lot of
complexity to the code, and I do not thing that the code nor this simple
feature deserve that.
Another option is to have each thread to report its progression
indenpently with all implementations, that what I did in the first
instance. It is much less interesting, but it would be homogeneous
although poor for every versions.
> We generally require features to work on all platforms we support. We
> have made occasional compromises there, but generally only when the
> restriction is fundamental to the platform rather than for developer
> convenience.
I agree with this kind of "generally", but please consider that "pthread
fork emulation" really means "processes", so that simple things with
threads become significantly more complex to implement.
--
Fabien.