You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We patch poll(2) with a JavaScript implementation. This PR resolves two problems in it:
### Infinite wait on poll(socketd, POLLIN)
Polling a socket for more data with `poll(socketd, POLLIN)` used to hang once the data was exhausted and the socket
closed because we never notified the caller about POLLHUP. We even have a related workaround in wordpress-components:
```php
$bytes = fread( $this->file_pointer, $n );
/**
* Workaround for a streaming bug in WordPress Playground.
*
* Without the feof() call, Playground doesn't notice when the stream reaches EOF.
* The feof() call in internal_reached_end_of_data() somehow does not trigger the
* EOF event. It must be here, right after fread().
*
* @todo: Improve the streaming support in WordPress Playground.
*/
feof( $this->file_pointer );
if ( false === $bytes ) {
throw new ByteStreamException( 'Failed to read from file' );
}
```
This PR makes poll(socketd, POLLIN) aware of a POLLHUP event. I'm not sure if that's POSIX-correct
and we should verify that before merging, but it actually solves the issue. CC @brandonpayton
### Not recognizing a socketd as socket
PHP.wasm supports child processes and keeps track of them in PHPWASM.child_proc_by_fd. However,
we never clean up the socketd => procInfo mapping. When a socketd number is getting reused, PHP
would mistakenly identify it as a child process and never poll the actual socket for data. This
PR works around it by testing for socket-ness first and for child-process-ness second. This is
ultimatly a hack. In a follow up PR we should find a way to actually remove closed socketd from
the child process map.
## Remaining work
* Test coverage
* Start an issue to actually cleanup child process ids
0 commit comments