How to sync object from threads

[ovr]

Hey! First thank for this awesome extensions

I was trying to implement multi thread support for ovr/phpsa in pthreads branch
ovr/phpsa@6380968

But i cant find "how to get all compiled files into 1 class"

ovr/phpsa@6380968#diff-517b2888759234ba4e6499d7280e98efR188

Maybe you can help me with good advice

Thanks 🍺

[krakjoe]

ovr/phpsa@6380968#diff-e8a18cb9f12d95361228e5249c4c3bceR30

If classes is a normal array, then this won't work as expected. You should initialize $this->classes as a Threaded object and use it like an array.

I'm not able to help further with testing because I don't have a working PHP5 environment, and phpsa doesn't seem to support PHP7 yet, are there plans to support seven soon ??

I'm going to close the issue, because this isn't a bug, but that's not the end of the conversation, feel free to ask more questions :)

[krakjoe]

ovr/phpsa@6380968#diff-e8a18cb9f12d95361228e5249c4c3bceR30

If classes is a normal array, then this won't work as expected. You should initialize $this->classes as a Threaded object and use it like an array.

I'm not able to help further with testing because I don't have a working PHP5 environment, and phpsa doesn't seem to support PHP7 yet, are there plans to support seven soon ??

I'm going to close the issue, because this isn't a bug, but that's not the end of the conversation, feel free to ask more questions :)

[ovr]

and phpsa doesn't seem to support PHP7 yet, are there plans to support seven soon

It supports PHP7 ;)

If classes is a normal array, then this won't work as expected. You should initialize $this->classes as a Threaded object and use it like an array.

Thanks you for advice, I will do it

I'm going to close the issue, because this isn't a bug, but that's not the end of the conversation, feel free to ask more questions :)

Thanks, take it 🍰

[ovr]

and phpsa doesn't seem to support PHP7 yet, are there plans to support seven soon

It supports PHP7 ;)

If classes is a normal array, then this won't work as expected. You should initialize $this->classes as a Threaded object and use it like an array.

Thanks you for advice, I will do it

I'm going to close the issue, because this isn't a bug, but that's not the end of the conversation, feel free to ask more questions :)

Thanks, take it 🍰

[krakjoe]

Yeah, my mistake ... I dug about a bit more this afternoon ... I got this far: https://github.com/krakjoe/phpsa/tree/phpsa/pthreads-fixes

This only supports PHP7 because it uses pthreads v3 features ...

It's rather slow to do it's work, I think getting battered by having to serialize all of PhpParser probably ... but it's probably a better starting point for you to play with ...

Ideally, you don't want to use volatile objects, but it seems programmed to require them right now ... find a way around that, if possible.

I found a bug in pthreads while digging, so pull current head of seven branch if you're going to test yourself ...

Feel free to holla when you get stuck again, I'll take another look ;)

[krakjoe]

Yeah, my mistake ... I dug about a bit more this afternoon ... I got this far: https://github.com/krakjoe/phpsa/tree/phpsa/pthreads-fixes

This only supports PHP7 because it uses pthreads v3 features ...

It's rather slow to do it's work, I think getting battered by having to serialize all of PhpParser probably ... but it's probably a better starting point for you to play with ...

Ideally, you don't want to use volatile objects, but it seems programmed to require them right now ... find a way around that, if possible.

I found a bug in pthreads while digging, so pull current head of seven branch if you're going to test yourself ...

Feel free to holla when you get stuck again, I'll take another look ;)

[ovr]

@krakjoe
What do you think about
"Implement fake php layer for pthreads"

If pthreads is not loaded use php layer withou threads like a fake sytem for lazy users or who are not interested to setup php-zts and pthreads

[ovr]

@krakjoe
What do you think about
"Implement fake php layer for pthreads"

If pthreads is not loaded use php layer withou threads like a fake sytem for lazy users or who are not interested to setup php-zts and pthreads

[krakjoe]

That could definitely be an option, I'm not sure exactly what it would look like, whether it would try to emulate threads, or satisfy execution requirements.

Probably leaning towards satisfying execution requirements, because if you tried to emulate threads you would just come up against people that don't have the necessary extensions for that.

[krakjoe]

That could definitely be an option, I'm not sure exactly what it would look like, whether it would try to emulate threads, or satisfy execution requirements.

Probably leaning towards satisfying execution requirements, because if you tried to emulate threads you would just come up against people that don't have the necessary extensions for that.

[krakjoe]

So a polyfill is quite easy, but integrating it a bit tricky because pthreads classes are in the root namespace.

Is there some composer voodoo that I don't know about that we could use ?

[krakjoe]

So a polyfill is quite easy, but integrating it a bit tricky because pthreads classes are in the root namespace.

Is there some composer voodoo that I don't know about that we could use ?

[ovr]

You can write composer.json like

    "autoload": {
        "files": ["src/pthread.php"],
    }

pthread.php

if (class_exists('threaded', false)) {
    class Threaded {
    }
}

[ovr]

You can write composer.json like

    "autoload": {
        "files": ["src/pthread.php"],
    }

pthread.php

if (class_exists('threaded', false)) {
    class Threaded {
    }
}

[ovr]

What do you think about this variant?

[ovr]

What do you think about this variant?

[krakjoe]

It's either that, or move all of pthreads classes into a namespace ... I'm not sure about moving all classes to a namespace, even with aliases registered it adds complexity and makes documenting a bit harder (and duplicates in the php manual) ... so this seems to be the nicest option, I think ...

[krakjoe]

It's either that, or move all of pthreads classes into a namespace ... I'm not sure about moving all classes to a namespace, even with aliases registered it adds complexity and makes documenting a bit harder (and duplicates in the php manual) ... so this seems to be the nicest option, I think ...

[krakjoe]

https://github.com/krakjoe/pthreads-polyfill/

There's a starting place I think ... this is not a complete implementation but allowed me to run the Pooling.php example distributed with pthreads, I'll aim to pass as much of the test suite as makes sense ...

[krakjoe]

https://github.com/krakjoe/pthreads-polyfill/

There's a starting place I think ... this is not a complete implementation but allowed me to run the Pooling.php example distributed with pthreads, I'll aim to pass as much of the test suite as makes sense ...

[ovr]

https://github.com/krakjoe/pthreads-polyfill/blob/master/src/Threaded.php#L17
Now, I understand an idea about synchronization

[ovr]

https://github.com/krakjoe/pthreads-polyfill/blob/master/src/Threaded.php#L17
Now, I understand an idea about synchronization

[ovr]

So, now it's a big problem
TO support pthread v3 and pthread v2
Maybe we can create a pollifl to support pthread v3 api on pthread v2 api?

[ovr]

So, now it's a big problem
TO support pthread v3 and pthread v2
Maybe we can create a pollifl to support pthread v3 api on pthread v2 api?

[ovr]

https://github.com/krakjoe/pthreads-polyfill/

Nice work 👍

[ovr]

https://github.com/krakjoe/pthreads-polyfill/

Nice work 👍

[krakjoe]

The actual API differences between 2 and 3 are minimal, a few removed methods from Threaded and the removal of Mutex/Cond (which nobody should have been using anyway), and moving Pool::collect to Worker::collect ... not really sure what to do about compatibility between them but I am thinking about it and will attempt to do something ...

It was your idea, I just wrote some code, thanks for taking the time ;)

[krakjoe]

The actual API differences between 2 and 3 are minimal, a few removed methods from Threaded and the removal of Mutex/Cond (which nobody should have been using anyway), and moving Pool::collect to Worker::collect ... not really sure what to do about compatibility between them but I am thinking about it and will attempt to do something ...

It was your idea, I just wrote some code, thanks for taking the time ;)

[krakjoe]

So now it fills for v2 and v3, but you shouldn't use Threaded::lock or Threaded::unlock, and I'm not going to fill in Mutex or Cond because nobody should be using those.

Untested against v2 .. I'll leave that to others ;)

[krakjoe]

So now it fills for v2 and v3, but you shouldn't use Threaded::lock or Threaded::unlock, and I'm not going to fill in Mutex or Cond because nobody should be using those.

Untested against v2 .. I'll leave that to others ;)