A few questions before using it

[SmetDenis]

Good afternoon, @hschimpf

First of all, I want to say thank you for your work. It looks very good.

I am very interested in your project as a lightweight alternative to amphp/parallel. It pulls a lot of dependencies, and I really don't like it.

I'm seriously considering it for my project https://github.com/JBZoo/Csv-Blueprint

Exploring your code, I have a few questions:

• Why do I need to use a separate loader? I've looked at the references in your readme, but it's still not clear to me.

• I noticed that you haven't run [autotests in GA]https://github.com/hschimpf/parallel-sdk/actions for a long time, although the last changes were a few days ago. Of course, on my local, I have everything working fine, and the tests have been completed successfully. Is this how it should be?

• Are you using a static code analyzer, such as phptan, psalm, phan, etc? I just didn't see it as part of your GA workflow.

• What about PSR12?

• Do you have any autotests to check that everything works as expected if the ext-parallel module is not loaded?

Sorry for these questions. It's just that before I use something, I thoroughly research libraries to be sure of my choices for the future.

Thank you in advance.
Best regards, Denis.

[SmetDenis]

In fact, if you don't have time for these improvements, let me know. I'll just make a fork.

[hschimpf]

Hello @SmetDenis,

Thank you very much for reaching out and showing interest in the project. I appreciate your thorough exploration and the questions you've posed. I'm happy to provide more information.

1. Separate Loader

Behind the scenes, the parallel extension creates an empty Runtime (thread) where the tasks are executed. Every Runtime is a clean, empty, isolated environment without any preloaded classes, functions, or autoloaders from the parent thread/process. This isolation ensures that each runtime starts with a minimal footprint.

An explanation can be found in Runtime Bootstrapping.

When a new runtime is created, it does not share code with the thread (or process) that created it. This means it doesn't have the same classes and functions loaded, nor the same autoloader set. In some cases, a very lightweight runtime is desirable because the tasks that will be scheduled do not need access to the code in the parent thread. In those cases where the tasks do need to access the same code, it is enough to set an autoloader as the bootstrap.

I'll make sure to add that link and explain this more clearly in the project's README file for everyone.

2. Scheduled GitHub Actions (GA)

You noticed correctly! The automatic tests were not running for a bit due to GitHub's policy of disabling scheduled workflows after 60 days of inactivity in the repository. I thought that pushing changes would kick-start them again, but it turns out to be a manual process. I've since re-enabled the scheduled tests, so future changes will be tested automatically again. Thanks for bringing this to my attention.

3. Static Code Analyzer

At present, static code analysis tools like PHPStan, Psalm, or Phan are not integrated into the GA workflow. This integration would indeed boost the project’s code quality and maintainability by catching potential bugs and code smells early in the development process. Incorporating such tools is on the roadmap as the project evolves.

4. PSR-12

I haven’t been strictly following PSR-12 standards. Instead, I use my own setup in PHPStorm that's pretty close to them. I try to keep the code neat and readable, but I might not follow every rule to the letter. I'll think about sticking closer to PSR-12 to make the code more standard.

5. Tests without ext-parallel

One of the main goals of the project is to ensure that the client's implementation of the library will work even in environments lacking the parallel extension (non-ZTS environments), when possible.

Currently, the test suite skips tests that are dependent on the parallel extension when it's not available.

That being said, most tests should run fine without it, except those that really need the parallel extension to work. I'll be working on adding tests to cover non-ZTS environments to ensure everything is smooth and reliable.

---

I hope these answers address your inquiries. Your attention to detail is highly valuable as I strive to make this project robust, flexible, and accessible. Please feel free to reach out if you have more questions or suggestions.

BR

[SmetDenis]

Oh, great.

Thanks more for the detailed answer. Honestly, I didn't even think to get answers so detailed.

I think I will start using the SDK at my tool soon. I might have some new questions. I'll be sure to make a new Github issue or something for them.

Yes, I especially like that the library will decide how to run tasks, in a common thread or in parallel (depending on ext-parallel availability). It's simple, easy and doesn't pull a dozen dependencies.

Thanks a lot, @hschimpf! I will look forward to my first experiments.