Event loop hangs after calling exists

[razshare]

Hey, I'm trying to prepare migrating a large codebase from amp v2 to v3 and so far everything has been really smooth, which is impressive, also the documentation and the short descriptions on the github releases page saying what replaced what from v2 to v3 helped a lot.

However I'm having an issue with \Amp\File\exists, it seems to be causing revolt's event loop to hang.

I prepared a repository that reproduces the error as I'm seeing it
https://github.com/tncrazvan/amp-v3-event-loop-hangs-after-exists

I'm running the script and then my event loop seems to hang forever.

However if I run some other async operation other than exists, everything works fine, the event loop stops as expected.

These are my php version and modules

PHP 8.2.7 (cli) (built: Jun  8 2023 15:27:40) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.7, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.7, Copyright (c), by Zend Technologies
    with Xdebug v3.2.1, Copyright (c) 2002-2023, by Derick Rethans
[PHP Modules]
calendar
Core
ctype
curl
date
dom
exif
FFI
fileinfo
filter
ftp
gettext
hash
iconv
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
random
readline
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
uuid
xdebug
xml
xmlreader
xmlwriter
xsl
yaml
Zend OPcache
zlib

[Zend Modules]
Xdebug
Zend OPcache

And this is my os release

Distributor ID:	Pop
Description:	Pop!_OS 22.04 LTS
Release:	22.04
Codename:	jammy

[kelunik]

Thanks for reporting! I can reproduce the issue, seems to be the ipc or result pipe of amphp/parallel.

[trowski]

@tncrazvan Was this fixed with amphp/parallel@v2.2.5?

[trowski]

Pulled your reproducer and it no longer hangs.

[razshare]

Hey, I've just tested the reproducer again and the issue seems to persist.

I've managed to debug it a bit.
From what I've gathered so far this might be a policy issue on how workers are executed rather than a bug.

I've noticed that amphp/parallel will start at least 1 worker (up to 32) whenever submitting any task, aka populating the pool.
I believe this to be the relevant piece of code that starts the workers.

These pool workers seem to be staying up forever, which is fair enough, that's what a pool worker is supposed to do.

Now the issue I think is that there's currently no way to hint to amphp/parallel that my program is about to end and I want to destroy my workers (unless there actually is a way to do that and I'm missing it).

I've come to this conclusion by checking my system processes and debugging the revolt event loop.

I've thrown a few echos into the revolt loop just to illustrate what's going on (I'm altering this part to be clear)

private function createLoopFiber(): void
{
    $this->fiber = new \Fiber(function (): void {
        $this->stopped = false;

        // Invoke microtasks if we have some
        $this->invokeCallbacks();

        /** @psalm-suppress RedundantCondition $this->stopped may be changed by $this->invokeCallbacks(). */
        while (!$this->stopped) {
            echo "looping\n";       // <======= HERE
            if ($this->interrupt) {
                $this->invokeInterrupt();
            }

            if ($this->isEmpty()) {
                return;
            }

            $previousIdle = $this->idle;
            $this->idle = true;

            $this->tick($previousIdle);
            $this->invokeCallbacks();
        }
    });
}

And this is the result

The program should and after the it exists echo, but as you can see it keeps going, because the workers are still up.

Note
The event loop also seems to be alternating between blocking and non blocking dispatching here, it happens because this variable alternates between true and false forever, although I'm not sure if that's supposed to be happening or not.
I'm not well versed in the internals of the project so I thought I should point that out, maybe it's helpful.

And finally I can see the worker among my system processes

As soon as I kill that process, the event loop unlocks and the program ends.

---

I personally don't think the workers are behaving wrong... I'm ok with them going on forever, but is there a way to stop them safely and on demand?

[trowski]

Thanks @tncrazvan for looking into this again and finding it was still an issue. I seem to have forgotten I had UV enabled when I tested, so of course a parallel worker wasn't being used for file access.

I found where there was still a referenced event-loop callback waiting for the worker result and refactored to avoid that callback being referenced unless the result is actively being awaited. This should now be fixed with amphp/parellel@v2.2.6.

[razshare]

@trowski I can confirm from my side everything works smooth as butter now! Thank you!