Let extensions accept Io\Poll\Handle objects

[nicolas-grekas]

php_poll.h exports php_poll_handle_get_fd() and the handle object struct under "utility functions for extensions", but not the class entry of Io\Poll\Handle, so an extension cannot check that an object is a handle before running PHP_POLL_HANDLE_OBJ_FROM_ZV() on it, other than by looking the class up by name. This exports the entry, plus a resolver for the common case of a parameter that takes more than a handle:

php_poll_handle_object *handle = php_poll_handle_from_zval(zv);

if (handle != NULL) {
    php_socket_t fd = php_poll_handle_get_fd(handle);
}

What it is for: ext-ev, ext-event and ext-uv could then take an Io\Poll\Handle where they take a stream or a descriptor today, resolve it in C and keep a reference to the handle while they watch it, so a handle provided by an extension works with the event loops that are not Io\Poll. That is the alternative to handing the descriptor to userland, which is what #23792 removes.

php_poll_handle_default_ops was declared without PHPAPI too, so an extension providing its own handle type cannot link it on Windows.

/cc @bukka

[bukka]

It might be too late for this and I'd rather not expose it yet for other extensions. It's specifically meant for the poll API at this stage.

[bukka]

Just to clarify the reason here - it's because I plan to introduce some other handle types for 8.7 and I would like to make sure that the internal API is consistent because not all of them will support fd's so it might need a bit of considering to make sure that things are right.

[nicolas-grekas]

Works for me. Note that it seams ext-ev / ext-event might be dead and while ext-uv might be well supported, I don't know maintainer's plan for 8.6 (see amphp/ext-uv#120 & amphp/ext-uv#121)
Closing, thanks for the feedback, let's keep this in mind for the future, possibly not needed.