Hhvm: Using HHVM with pthreads

[BurakDev]

Hello, I use pthreads and APC on my project.

When I start my file with hhvm, I get error : "Thread class not found", HHVM don't support php pthreads ?

Thanks in advance

[fredemmott]

Sorry, we don't currently support pthreads.

[BurakDev]

Is in to-do list ?

[fredemmott]

Yep, github issues are the todo list.

[lbadger]

+1

[MartinMajor]

+1

[TruDan]

+1,000

[0147500]

+1

[MCMrARM]

+1

[michaeldoehler]

+1

[msjyoo]

+1

[paulbiss]

This is something we are interested in having in some form. Currently the way requests are implemented isn't thread safe, and getting this to work will likely require support from the on-going GC project. I doubt it's something we'll be ready to invest time in soon.

[michaeldoehler]

@paulbiss Requests are safe or not ? - 5 months ago, the requests are thread safe, but now not? see https://github.com/facebook/hhvm/issues/4719

Correct my, if i am wrong, but you have several threading capabilities implemented, e.g. pagelet server, xbox tasks, rpc, etc.?! - Everything looks like threading is nothing new to HHVM and maybe this should be good starting points (ideas...) to porting pthreads to HHVM or?

[fredemmott]

Same story as 5 months ago: for each request, PHP code for one request always executes in the same thread, so thread-safety is not an issue.

Pagelets and xbox etc are implemented as extra requests, without sharing context, so thread-safety is still not an issue there.

[BurakDev]

UP ? PHP7/PHPNG will support it. Maybe @krakjoe will work on HHVM compatible version

[krakjoe]

I don't know enough about HHVM to do that, and am super busy on 7 related stuff, so don't have the time to learn ...

[aftabnaveed]

+1 for threading support, I don't care if Zend won't do it. HACK should do it.

[fredemmott]

Closing this, as if this happens, it's almost certainly going to come in one of two ways:

• us implementing a limited API that fits our needs, and is hopefully useful for others
• us merging an external extension (if you look at this and want to start one with the goal of having it merged, please pay close attention to the licenses and our CLA, and get suitable CLAs from any other contributors so that it's actually possible for us to merge it)

As our needs are somewhat specialized, if we try to design and implement something useful for others we're likely to not have the right context and accidentally make something useless that we need to support.

As for the model provided by PHP's pthreads extension, this is not a good fit for HHVM, as HHVM is multithreaded, with lots of per-request context being stored in thread-local storage; this means that a single request/script _can not_ have PHP code executing in multiple threads in the same context without substantial changes to HHVM. This would be a huge one-off cost and likely have performance implications that would mean we couldn't merge it anyway; given the limited demand and other unrelated issues that we could work on instead, this would not be a good use of our time.

I guess the most likely form would be something like: run in another thread, which will not share globals, can not use pass-by-reference from the caller, can not "use" variables', and any communication back to the parent thread must be via the return value, out of band (eg files), or by passing pipes into it.

[fredemmott]

^ won't fix is just that _we_ won't fix it. We'll be happy to review and consider merging external implementations.