ju1ius

The build fails when the `closure` feature is enabled. ``` error[E0046]: not all trait items implemented, missing: `BUILDER_MODIFIER`, `EXTENDS`, `IMPLEMENTS`, `method_builders`, `constructor`, `constants` --> /ext-php-rs/src/closure.rs:152:1 | 152 | impl RegisteredClass...

@joelwurtz I'm not sure I understand... I have the feeling that you're confusing `modules` with `extensions`. Modules are loaded from ini entries (`extension=libfoo.so`) and must export a `get_module` symbol which...

> I was correctly talking about a PHP extension Yes the fact that these terms are mixed and matched in the source PHP source code and documentation is rather unfortunate...

> because all the variables are managed by php runtime. As far as I understand that's precisely what makes it not safe. The PHP runtime is not thread safe, even...

If you're going to spawn threads, I would suggest you to follow a method similar to what the [parallel extension](https://www.php.net/manual/en/philosophy.parallel.php) does (CSP concurrency AKA message passing over channels). You'll avoid...

> I've added async support to ext-php-rs in [danog/php-tokio](https://github.com/danog/php-tokio), it seems like this is what you were looking to do when you opened this issue :) Good if it works...

> it's actually perfectly safe No, it is not. Rust references are not raw pointers. If you want an unbounded lifetime, you __must__ use a raw pointer. Transmuting the lifetime...

Sorry, but that was not my point. I have no doubt that you have carefully checked the semantics of this. Still, transmuting the lifetime of a reference like this is...

> I'm well aware that this is undefined behavior, Then why not just using raw pointers instead? 😉 > If you're worried about undefined behavior in a library that interacts...

FYI, the issue is still present on the latest stable flatpak release from flathub.