[BUG] PHP7.2 broken after this commit

[temuri416]

Hi,

This commit broke my pthreads:
de5d8f2

Happens when more than one task is submitted to the pool.

Getting bizarre error as a result - value of application-wide constant PATH_VENDOR on third execution gets assigned a name of composer's autoload function instead of the directory name.

I'm on PHP 7.2.

Unfortunately it is near impossible to provide you with the reproducible code - you would need the entire application.

Can anything be done about it?

Thank you!

[dktapps]

Please see #939 for fix. You might also look at https://github.com/pmmp/pthreads/tree/fork , it contains some other fixes which aren't in the main repo.

[temuri416]

Thanks! Will it all be merged into main repo or should I switch to using fork?

[dktapps]

I have no idea. All the maintainers are inactive right now. I've been using the fork in production for many months.

[sirsnyder]

@dktapps I'm here, but mostly in the background. My project in the garden ends slowly and then in the coming days / weeks I will dedicate myself more to the project. We are approaching the 7.4 release and thus the end of this great project. I'm planning a fork / project with a new name, namespace support, revised API and other features. It would be great to have you with it, but it can also be understood if you want to focus more on your pthreads fork.

[dktapps]

@sirsnyder I haven't decided how to move forwards with 7.4 yet.

Migrating all the PM things to anything other than pthreads is going to take a lot of time, since they don't interop very well, which means all the infrastructure changes needed to migrate would have to happen all at the same time. I figured that in the short term it would be less work to update pthreads, regardless of whatever impact it has on JIT or anything else.

I've considered removing various maintainability nightmares from my fork and making it more like parallel (f.e. always relying on autoloading removes the pain of class copying), and also various API changes (Threaded needs to be split up), but I don't know if enhancements to it are worth the time I have.

One thing that @krakjoe has right is that pthreads is far too complex.

@sirsnyder What is the status of your fork /project idea? I'm quite interested in using pthreads in PHP 7.3 and 7.4.

Since parallel has its limitations, pthreads is sometimes needed exactly because of its complexity it allows the freedom to do "anything".