-
Notifications
You must be signed in to change notification settings - Fork 1.9k
async parser handler support #3222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 26 commits
Commits
Show all changes
30 commits
Select commit
Hold shift + click to select a range
bc10480
early version of async support for CSI and ESC handlers
jerch 0ad9f70
Merge branch 'master' into async_handlers
jerch 4a1bdad
fix tests for async handlers in inputhandler
jerch adfeffe
deprecate writeSync
jerch 22d777c
make linter happy
jerch b07ca8b
fix timeout issue on macos
jerch 2f07ed9
simplify stack save in parser
jerch 4ba7aef
Merge branch 'master' into async_handlers
jerch a9eb1de
Merge branch 'master' into async_handlers
jerch 68b7f88
async parser tests for CSI and ESC
jerch 898a18d
Merge branch 'master' into async_handlers
jerch d59f4d2
async impl for DCS, DcsParser tests
jerch 041e259
OSC impl, OscParser tests
jerch d0b5556
update parser hooks api and tests
jerch 5db479c
update public API
jerch 2650211
minor tweaks, API docs update
jerch bce3269
async OSC/DCS registering/dispose tests on parser instance
jerch 9985ae2
fix linter warning
jerch d500b0f
inputhandler tests
jerch 6b57921
async handler API tests
jerch b4635ed
make reset async aware
jerch 26bf1ab
Merge branch 'master' into async_handlers
jerch cc005a2
multiple changes:
jerch 48a93c3
log a warning if an async handler takes too long
jerch cdd238d
do not timeout on faulty async handlers, continue with false to give …
jerch c19cc9b
Merge branch 'master' into async_handlers
jerch a748845
Merge branch 'master' into async_handlers
jerch 76fdf9d
Merge branch 'async_handlers' of github.com:jerch/xterm.js into async…
jerch 8e7cdd2
interface for inputhandler parse stack, proper typing of LogService.l…
jerch 869c11f
interface for subparser stack saves
jerch File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI this will take a little while to adopt in vscode, it's used currently in the local echo and reconnect features. It's also used in a bunch of tests which I think should be harmless to stay.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we also had many tests with
writeSync, but those were easy replaced by awritePimplementation:xterm.js/src/browser/TestUtils.test.ts
Lines 24 to 26 in 26bf1ab
I used the same
methodPidea for testing the methods along the async callstack:xterm.js/src/common/InputHandler.test.ts
Lines 50 to 56 in 26bf1ab
For the deeper calls it is a bit more cumbersome to get done right, thus my warnings all over the place not to call those methods directly anymore. Note that it always was dangerous to directly inject chunks at those lower levels while
Terminal.writestill holds data (will mess up parser states even in sync mode), but now with async it is even more dangerous as it might break the proper continuation. Lets hope that ppl dont dismantle the callstack and call the lower methods directly. Also I dont know of any TS way to prevent that, is there an access pattern likefriendin C++?Final note on
writeSync- I did not remove it yet, because it will keep working as before as long as there are no async handlers hooked into the parser. It even keeps working with async handlers if pending data does not trigger any async action (thats what I meant with promise islands - you can still sail in sync water normally at high speed, but now there are promise shallow regions where the boat can crash if not used withwriteP). Initially I thought about marking async handlers statically, so the parser would have a "map" of promise regions, but that turned out as not being helpful, as it cannot be decided prehand without actually parsing the data. Thus I went with the simpler handling of "whenever a promise is returned, it is an async handler" (effectively sailing on "runtime sight").