Repository navigation
ftp functions can abort with EINTR #16800
Description
Activity
I agree
I'm willing to look into this. It's a bit annoying because the polling API does not give us an updated timeout value, so we need to track it ourselves. I thought about using
select()instead ofpoll(), but only on Linux does that actually update the timeout value :(Maybe, such a wrapper around the poll functionality should live in a general place
Yeah it could be useful. I see that it's actually timeout reduction does not seems to be always reduced by streams either - EINTR is handled but looks like timeout is not always handled ( e.g.
).php-src/main/streams/xp_socket.c
Lines 85 to 99 in 59ed9ce
We have been discussing new polling API for some time so this is something that should be there for sure. But even having some common helpers in the meantime would be helpful.
- added a commit that references this issue
on Jan 2, 2025 - linked a pull request that will close this issueFix GH-16800: ftp functions can abort with EINTR #17327
on Jan 2, 2025 - added 2 commits that reference this issue
on Jan 3, 2025
Description
The underlying cause is poll(2) syscalls in the ext/ftp code (poll is one of those syscalls which cannot be resumed via SA_RESTART).
Short of guarding every single ftp operation, there's no way to cleanly resume ftp processing.
Especially given that the ext/ftp operations are sometimes big operations - like, I don't really have certainty on whether a transfer properly happened or not, I just know it was aborted.
my_send() and my_recv() in the ftp code both call php_pollfd_for_ms() and immediately abort on any non-zero return instead of retrying on EINTR.
The ext/ftp operations are high-level enough that they should handle EINTR themselves and resume accordingly.
PHP Version
PHP 8.3.13
Operating System
No response