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
I've been playing around with this project, and it seems to work very nicely. One issue I ran into was when using the synchronous interface. Since calls to reader.parse(...) block, it's very easy to fall into a black hole where the stream halts with what would be an Incomplete, but just stalls waiting to complete the parse and there is no opportunity to abort or notify the caller of this fact. Of course, you could get around this in an async environment, but it seems excessive to pull in a whole async runtime just to handle the stream stopping mid-parse. Maybe I'm wrong here though.
I suppose this is a direct consequence of having one of the project's goals be to save the user from having to deal with Incompletes and re-filling dynamics. However given that the purpose is also to do streaming parsers, I feel that this will be a common pitfall. Once you are parsing from a stream, odds are that you need to be able to handle that stream stopping part way through a parse.
I was able to get around this by just monitoring the buffer levels and not attempting to parse if it would be impossible to complete with the current fill level, but this is a bit of a hack and wouldn't work in many applications. Off-hand I can't think of a way to analyze the internal Incomplete state after the parse call that doesn't amount to just doing async, but could a timeout or some other escape hatch reasonable?
Thanks for all your work on Nom. It's a great project!
The text was updated successfully, but these errors were encountered:
kyzyl
changed the title
Timeouts on syncronous reads
Timeouts on synchronous reads
Dec 8, 2021
I've been playing around with this project, and it seems to work very nicely. One issue I ran into was when using the synchronous interface. Since calls to reader.parse(...) block, it's very easy to fall into a black hole where the stream halts with what would be an Incomplete, but just stalls waiting to complete the parse and there is no opportunity to abort or notify the caller of this fact. Of course, you could get around this in an async environment, but it seems excessive to pull in a whole async runtime just to handle the stream stopping mid-parse. Maybe I'm wrong here though.
I suppose this is a direct consequence of having one of the project's goals be to save the user from having to deal with Incompletes and re-filling dynamics. However given that the purpose is also to do streaming parsers, I feel that this will be a common pitfall. Once you are parsing from a stream, odds are that you need to be able to handle that stream stopping part way through a parse.
I was able to get around this by just monitoring the buffer levels and not attempting to parse if it would be impossible to complete with the current fill level, but this is a bit of a hack and wouldn't work in many applications. Off-hand I can't think of a way to analyze the internal Incomplete state after the parse call that doesn't amount to just doing async, but could a timeout or some other escape hatch reasonable?
Thanks for all your work on Nom. It's a great project!
The text was updated successfully, but these errors were encountered: