Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Io\Poll: data buffered by the stream layer is not reported, and a stream closed while watched is never reported

オープン
  • 何か問題がありますか？
#23,948 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, linux, php
領域
api, backend, operating-systems

調査の方向性

Start by tracing Io\Poll Context::wait(), StreamPollHandle, and the Linux epoll backend, then reproduce both cases from the issue: buffered stream data and a watched stream closed during a wait. Done means wait() reports buffered reads and reports a watcher retired by close, with behavior comparable to stream_select().

索引モデルが issue の本文から書いたものです。

説明

Category: IO Category: Streams
Description

@bukka — I've been writing a poller for phasync (a coroutine library) on top of Io\Poll, next to our stream_select() one, and ran our test suite against master. Two behaviours make a correct event loop hard to build on it, and both differ from stream_select():

1. Data already in the stream's read buffer isn't reported. After a read that buffered more than it returned (typical with fgets()), the socket is empty but the stream has unread data. stream_select() counts that stream as readable; Io\Poll only looks at the fd, so a loop that waits for readability before its next read never wakes.

use Io\Poll\{Context, Event};

[$a, $b] = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, STREAM_IPPROTO_IP);
fwrite($b, "first\nsecond\n");
fgets($a); // "first\n"; "second\n" is now in $a's read buffer, the socket is empty

$r = [$a]; $w = $e = null;
var_dump(stream_select($r, $w, $e, 0));   // int(1)

$poll = new Context();
$poll->add(new StreamPollHandle($a), [Event::Read]);
var_dump(count($poll->wait(Time\Duration::fromMilliseconds(100)))); // int(0)

We work around it by checking stream_get_meta_data($s)['unread_bytes'] before every wait, but every user of the API will hit this. Perhaps wait() could return the watchers of streams with buffered read data at once (as stream_select() does through stream_array_emulate_read_fd_set()), with Event::Read triggered.

2. A stream closed while watched is never reported. Since #23822, fclose() retires the watcher (which fixed the use-after-free), but wait() never tells the loop. A coroutine or callback waiting on that stream waits forever, unless the loop scans every watcher's isActive() periodically and caps its waits to do so:

use Io\Poll\{Context, Event};

[$a, $b] = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, STREAM_IPPROTO_IP);
$poll    = new Context();
$watcher = $poll->add(new StreamPollHandle($a), [Event::Read]);

fclose($a); // elsewhere in the program, while something waits on $a
var_dump($watcher->isActive());                                       // bool(false)
var_dump(count($poll->wait(Time\Duration::fromMilliseconds(100))));   // int(0): nobody is told

With stream_select() the next call throws on the closed stream (TypeError, or ValueError when it was the only one), so the loop can find and wake its waiter. Perhaps the next wait() could return a watcher retired by a close once, inactive, (e.g. with Event::HangUp triggered), so the loop wakes its waiter without scanning.

Let me know if you'd like me to write a PR for either.

PHP Version
PHP 8.7.0-dev (master)
Operating System

Linux (epoll backend)

主要言語
C
スター
40.7k
フォーク
8.3k
平均マージ
2日 16時間
マージ済み PR（30日）
151

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

php/php-src のほかの issue

php/php-src の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。