Delphi-Promises use of the threading module

[pyscripter]

Congratulations for this excellent work!

After superficially looking at the source code, I saw that you use the System.Threading.TTask to run the long running procedure ControlPool. On the other hand you use a custom thread pool with worker threads to run everything else. ControlPool creates a minimum of 10 worker threads at start (sounds wasteful for light usage, even if the overhead of creating threads is not large).

I always thought that TTask is for short tasks. For long-running tasks (in this case for the lifetime of the application) you are better off to create a dedicated thread. Instead the procedures you run in the custom pool, sound like ideally suited for TTask.

Could you please explain:

• Why you run ControlPool as a Threading.TTask. If you run it in a dedicated thead you could decouple Delphi-Promise from System.Threading.
• Why you chose to implement your own custom thread pool and not use the System.Threading machinery? Running two thread pools in parallel may be wasteful.

[Laurensvanrun]

Thanks for your feedback!

To be honest, there is no specific reason why ControlPool is executed as a TTask. You are absolutely right that TTask is meant to be used for short tasks and I think that executing it in a dedicated thread would be a better solution.

The reason why I choose to implement a custom thread pool is that we want full control over it. Relying on the amount of thread in the System.Threading engine would be too risky. In our real-world situations, we have seen that 50+ threads are not enough in some situations (especially when using Promise.All) and that is why we want full control here. When you start chaining promises (especially in a nested setup with multiple REST or other I/O calls), you will easily use 5-10 threads. That is why we decided to use 10 threads as the default, but this minimum is of course debatable.

[pyscripter]

Thanks for the explanations.

I know I am probably asking too much, but It would be nice if there was an option to use the threading module instead of the custom pool. This would help avoid operating two thread pools in parallel for users that;

• already use the threading module for other purposes and
• make light use of delphi-promises

[Laurensvanrun]

Feel free to create one and experiment with it. If it performs better in all situations we could replace the current one or make it optional. I am very curious about your PR.

One question, what is your main reason to reduce the resource usage?

[pyscripter]

One question, what is your main reason to reduce the resource usage?

Yes, but also simplicity, You would have just one pool to monitor, get performance stats, debug etc. The threading module pool is quite configurable.