Reintroduce proc_open_multiplex.phpt #17192
Conversation
The main intent of the test was to show the changed behavior on Windows; previously, `stream_select()` would return immediately there, reporting all pipes as ready; now, it only returns if at least one pipe is actually ready. The original test case was overspecified; of course, we cannot assume that the pipes are ready one after the other; depending on the concrete `select(2)` implementation and the system scheduler, minor differences are to be expected. Thus we relax the test expectations, and now require that not all pipes are reported ready after a single `stream_select()` call, and that the output contains all strings. We also ensure that `stream_select()` doesn't fail (for whatever reason). And in case of the test expectations not being met, we also output some diagnostics (most notably the output that has already been read).
|
I've retriggered both macOS jobs, and they passed again, so this might be good this time. |
| ]; | ||
| $read_pipes = []; | ||
| for ($i = 0; $i < 10; $i++) { | ||
| $procs[] = proc_open([$php, "-r", "usleep(100000 * (10 - $i)); echo 'hello$i';"], $desc, $pipes); |
There was a problem hiding this comment.
Does it really need to take the whole second (10 x 100ms) to test this? I think it should work for shorter interval to test what is tested here.
There was a problem hiding this comment.
I've reduced to 10 * 10ms, and CI is still green.
|
It seems this job can fail: https://github.com/php/php-src/actions/runs/13868159277/job/38811107251 |
|
Testing it in an interactive session and it seems to work there consistently running it quite a few times. My guess is it might be runner environment, (i.e. PTYs? though this test doesn't use PTYs, just piped I/O) but I'm not certain about that. |
The main intent of the test was to show the changed behavior on Windows; previously,
stream_select()would return immediately there, reporting all pipes as ready; now, it only returns if at least one pipe is actually ready.The original test case was overspecified; of course, we cannot assume that the pipes are ready one after the other; depending on the concrete
select(2)implementation and the system scheduler, minor differences are to be expected.Thus we relax the test expectations, and now require that not all pipes are reported ready after a single
stream_select()call, and that the output contains all strings. We also ensure thatstream_select()doesn't fail (for whatever reason). And in case of the test expectations not being met, we also output some diagnostics (most notably the output that has already been read).