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
So in the simple case the error propagation works as expected as shown in the map error tests and the macro that does the heavy lifting.
Now I believe the core problem exists with how we set up the reactor pipe-chain but I believe that will be a problem assessed in bringing godot to v1.0.0.
Anyways, somehow when there is an influx of errors being emitted from a reactor primitive, the stream is stalled and can no longer accept anymore events. I think the best approach to take is to do some dtrace testing on how the bottleneck is created underneath the hood.
How its supposed to behave is the error handlers here are placed to propagate the reactor's errors to the reactor instance to then be handled by the server instance.
The text was updated successfully, but these errors were encountered:
When looking at an email from the nodejs mailing list, the fact that this "stalls" the stream makes a lot of sense. In the simple test case I put together, it shows that after the first error occurs, the beginning of the pipe chain receives the message, but it does not hit another error. If node internals somehow unpipe the stream that is erroring in the middle, it could explain this behavior.
I will be looking into how this is handled in node core.
It seems the dude in the email was correct. In core, a readable stream unpipes itself from the destination stream if the destination stream errors. This explains what is happening in our case here and we will need to adapt to handle this.
So in the simple case the error propagation works as expected as shown in the map error tests and the macro that does the heavy lifting.
Now I believe the core problem exists with how we set up the reactor pipe-chain but I believe that will be a problem assessed in bringing
godot
tov1.0.0
.Anyways, somehow when there is an influx of errors being emitted from a reactor primitive, the stream is stalled and can no longer accept anymore events. I think the best approach to take is to do some dtrace testing on how the bottleneck is created underneath the hood.
How its supposed to behave is the error handlers here are placed to propagate the reactor's errors to the
reactor
instance to then be handled by theserver
instance.The text was updated successfully, but these errors were encountered: