search

async-interop / event-loop

An event loop interface for interoperability in PHP.
MIT License
169 stars 9 forks source link

Watcher behavior regarding resources closed unexpectedly #99

Closed ghost closed 8 years ago

ghost commented 8 years ago

What is the expected behavior of read / write watchers when the watched resource is closed unexpectedly (broken pipe / remote peer closed a socket...)?

The doc comments in the Loop class read like this:

Execute a callback when a stream resource becomes readable / writable.

I implemented loop drivers based on stream_select(), ev and event. All of them report broken resources as readable / writable. Same thing with uv, it triggers polls with an empty event mask indicating a broken resource. I think the docs should be updated to include this case and define it as expected behavior.

kelunik commented 8 years ago

Good catch, yes. It should just trigger the callback. I don't know, should we automatically cancel the watcher in that case?

bwoebi commented 8 years ago

No, we shouldn't introduce automagic behavior here. (If you don't cancel, your CPU will anyway spike, so it'll be easy to spot in any case.) Especially problematic in the case the stream is closed and there still was some data in the buffer, but was completely consumed in the callback. Now, do we assume that the callee has already taken care of freeing related data or do we nevertheless call them again? Sure, we could solve this with a well-defined specification, but that's unnecessary complexity.

Anyway, added PR #100 for clarification about the closing. — After that PR is merged I will add a test to the event-loop-tests repository ensuring correct behavior after closing.