Skip to content

fpm: Convert to new internal polling API#22796

Draft
NattyNarwhal wants to merge 7 commits into
php:masterfrom
NattyNarwhal:fpm-poll
Draft

fpm: Convert to new internal polling API#22796
NattyNarwhal wants to merge 7 commits into
php:masterfrom
NattyNarwhal:fpm-poll

Conversation

@NattyNarwhal

@NattyNarwhal NattyNarwhal commented Jul 18, 2026

Copy link
Copy Markdown
Member

Very hacky first pass! Gets rid of FPM's own polling backends (only select is the casualty, everything else is handled by the new polling API). The polling API also has some stuff for persistent allocations, and FPM is the first internal consumer it seems.

Testing so far on macOS (kqueue) and Linux (epoll),

Concerns so far:

  • FPM's polling modules skipped EINTR, internal polling API does not. Moved EINTR ignoring to fpm's loop, but may be a problem on Solaris?
  • Timeout code is a little weird. Doesn't seem to cause any issues so far.
  • Multiprocess FPM is a little annoying to debug...

You may need to hack up the poll backends to not return an error on
EINTR. Passes a lot of tests, but need to deal with leak strategy.
Allocate the buffer at the beginning. There is a bit of glue for going
between the linked list that FPM uses for record keeping vs. the buffer
of FDs that poll API returns, but it's minimal.

This does leak memory, so a few more tests fail. Need to figure out
strategy for that.
In the poll/kqueue/epoll backends, these would return an error without a
warning or processing the results. Do the same here.

Note that the old fpm Solaris event ports backend could handle the case
of EINTR/ETIME with returned results. I don't think the internal polling
API handles that, but I don't have a Solaris system to test with.
Don't use ZendMM; relocate comment to more sensible spot.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant