-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
Inconsistent pipeline thread stack size #17407
Comments
#6224 brought the 10MB default from Windows PowerShell for local pipeline into PowerShell. Any reason why the same limit isn't used for jobs and remote sessions? |
I think it makes sense to have the same limit. /cc @PaulHigin |
@WG-Remoting Remote execution of commands and script is more complex than with the local pipeline case. By default the remoting endpoint will run commands/script on the same thread the remoting message is processed on, to save the overhead of generating extra threads. In the Start-Job case, these are .Net threadpool threads and you cannot change the stack size on them AFAIK. There is a mechanism to change this default behavior and specify a |
I still believe this is worth a fix to provide a consistent environment for users regardless of how they invoke their code. |
@iSazonov Could we please reopen this? Still relevant and I don't like duplicating issues 🙂 |
@PaulHigin Thanks for the previous answer. Adding an option to Could you elaborate a little about the overhead with using an extra thread for remote sessions? Is it a <1sec delayed session start? Higher memory usage? |
Prerequisites
Steps to reproduce
Example 1:
Start-Job { function recurse([int]$i) { $i; recurse ($i+1) }; recurse 0 } | Receive-Job -Wait
function recurse([int]$i) { $i; recurse ($i+1) }; recurse 0
Example 2 on Windows:
Run the following block directly in Powershell session and then inside a job
Expected behavior
Actual behavior
Error details
No response
Environment data
Visuals
No response
The text was updated successfully, but these errors were encountered: