-
Notifications
You must be signed in to change notification settings - Fork 1.3k
don't try to prewarm an execution service #13377
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| Prevent daemon from trying to prewarm an execution service. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,7 +6,7 @@ | |
| import { ChildProcess } from 'child_process'; | ||
| import { inject, injectable } from 'inversify'; | ||
| import { IDisposable } from 'monaco-editor'; | ||
| import { IPythonExecutionService, ObservableExecutionResult } from '../../common/process/types'; | ||
| import { ObservableExecutionResult } from '../../common/process/types'; | ||
| import { Resource } from '../../common/types'; | ||
| import { noop } from '../../common/utils/misc'; | ||
| import { PythonInterpreter } from '../../pythonEnvironments/info'; | ||
|
|
@@ -47,14 +47,9 @@ export class PythonKernelLauncherDaemon implements IDisposable { | |
|
|
||
| // The daemon pool can return back a non-IPythonKernelDaemon if daemon service is not supported or for Python 2. | ||
| // Use a check for the daemon.start function here before we call it. | ||
| if (!daemon.start) { | ||
| if (!('start' in daemon)) { | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is where I'd made the previous fix to 2.7 non-daemon launching. But that funky type coming back from the daemon creation was still causing issues in other locations (such as with prewarm) so I converted the deamon create to return the actual type union that it creates and then make sure to handle the cases that might be different for a daemon versus an execution service. I should have changed it the first time around 😞 . |
||
| // If we don't have a KernelDaemon here then we have an execution service and should use that to launch | ||
| // Typing is a bit funk here, as createDaemon can return an execution service instead of the requested | ||
| // daemon class | ||
| // tslint:disable-next-line:no-any | ||
| const executionService = (daemon as any) as IPythonExecutionService; | ||
|
|
||
| const observableOutput = executionService.execModuleObservable(moduleName, moduleArgs, { | ||
| const observableOutput = daemon.execModuleObservable(moduleName, moduleArgs, { | ||
| env, | ||
| cwd: workingDirectory | ||
| }); | ||
|
|
||
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.
Would it make more sense to put this 'or' on the 'extends'? Or does that not work?
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.
I was thinking no, since the <> part I see as the "request" for what the user wants. Honestly IPythonDaemonExecutionService is almost the same as IPythonExecutionService so it could go together, but I felt like the distinction was important here between what users are actually request (some type of IPythonDaemonExecutionService) and the fact that if we can't create one then we just return an IPythonExecutionService.