Description
as discussed with Vlad:
Currently parallel backup or restore using gbak is fine. But parallel backup or restore using a service does not use the new setting in firebird.conf. Users would have to patch their connectivity libs to get parallel processing there too, since most libs lag years behind Firebird development.
The service manager should get the ParallelWorkers setting from the engine, which knows it from firebird.conf, and use that as default.
If some different value was needed when calling a service, one could still configure a service differently e.g. by setting isc_spb_res_parallel_workers, but the default should be taken from ParallelWorkers in firebird.conf.
The default legacy behaviour (no parallelisation) remains unchanged since the default for ParallelWorkers in firebird.conf is 1. If someone changes that setting, it would mean, use parallelisation whereever possible and these are the resources the box can provide. Conceptually similar to the connection pool setting ExtConnPoolSize, default 0, no connection pooling.
This way no one would have to patch their connectivity libs and would benefit from the new feature right now, out of the box, by just setting a number in firebird.conf. In the meantime maintainers could gradually update their libs to include the new switches.
This approach (use ParallelWorkers as default) could also be applied to any parallelisation, where that's not the case already.
This does not mean utilities like gbak which don't have access to firebird.conf, since there one can use cmd line switches.