Suggestion: Keep the GUI separate from the debloating tasks

[glibg10b]

Clicking a button in the GUI freezes it until the current task finishes. This means I have to wait for it to finish before I can start the next task. I suggest running the debloating tasks in a separate process and queuing tasks when pressing buttons while the program is busy.

I would recommend against starting a new process for every task, though. If too many tasks run in parallel, the system will lock up and start killing processes before they can complete.

[Sycnex]

Good point. I don’t have any experience with separating the processes from the main thread, but I imagine this could be done using Jobs. I’ll look into this. Thanks!

Sent from my iPhone

On May 22, 2021, at 12:52 PM, glibg10b @.***> wrote:

 Clicking a button in the GUI freezes it until the current task finishes. This means I have to wait for it to finish before I can start the next task. I suggest running the debloating tasks in a separate process and queuing tasks when pressing buttons while the program is busy.

I would recommend against starting a new process for every task, though. If too many tasks run in parallel, the system will lock up and start killing processes before they can complete.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[glibg10b]

I discovered today that one can queue actions just by clicking the buttons while the GUI is frozen, so implementing this might not be necessary

[Sycnex]

I was considering creating Jobs though still, Since it can make the script run much faster, plus I can have additional logging and reporting.

[Zoran-Jankov]

You could use Start-ThreadJob cmdlet for creating separate threads.