-
Notifications
You must be signed in to change notification settings - Fork 53
Create the first PowerShellManager instance when processing the first FunctionLoad request #201
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
Conversation
@TylerLeonhardt, I made more changes on top of #200 than I thought, so I just pushed a separate PR. |
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.
LGTM
…instance for downloading
It turns out we cannot have the dependency manager to create a separate Runspace for downloading. This refactoring make sure only one |
@TylerLeonhardt and @SatishRanjan Can you both please review this PR again? Thanks |
Design changed, need to be reviewed again.
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.
LGTM!
LGTM. Thank you @daxian-dbw for fixing the local debugging issue! |
This is to fix the regression in local debugging.
We create the first
PowerShellManager
instance when processing the firstFunctionLoad
request, so the debugger has the target Runspace to attach to.However, we delay the initialization of the first
PowerShellManager
instance until the first invocation (when checking out the instance from pool).It turns out we cannot have the dependency manager to create a separate Runspace for downloading.
The VS Code local debugging assumes the target
Runspace
hasId = 1
, which was true before as only one Runspace will be created initially.Now, the dependency manager creates a separate
Runspace
for downloading, and there will be a race condition -- sometimes theRunspace
created for the downloading hasId = 1
, and thus the debugger will attach to that Runspace, which will be reclaimed after the download and causing theWait-Debugger
in the user's function script to not be hit.This refactoring make sure only one
Runspace
is created initially -- thePowerShell
instance used for the downloading is also used to serve the first invocation request.So there is no race condition and local debugging can work reliably.
Fix #196.