advanced params refactoring + prevent users from skipping/stopping other users tasks in queue

[mashb1t]

Relates to #826
Fixes #713
Fixes #501

fixes inconsistency in behaviour of stop_button and skip_button as it was possible to skip or stop other users processes while still being in queue.

Expected:
sessions are completely separate, no interference or control by other users except yourself

Actual:
one can skip and stop tasks of others

Steps to reproduce:

1. open 2 tabs
2. click "generate" in tab 1
3. click "generate" in tab 2
4. see skip/stop button in tab 2
5. click skip/stop button in tab 2, task for tab1 skips/stops

this is also possible using x tabs, where the last tab clicking "generate" can skip all previous queued tasks

[lllyasviel]

yes this is a reasonable problem and should fix.
nevertheless this also disable me from stopping a task rightly after click generate.
previously i can click stop rightly after generate, though a bit laggy

[mashb1t]

shared.last_stop could be handled not in shared but in the AsyncTask object to achieve true separation. Then skip_clicked and stop_clicked could set the property on AsyncTask and the worker could handle the process accordingly.

What would be your proposal?

[mashb1t]

@lllyasviel skipping/stopping is now completely isolated, but a user can't skip/stop before the task is processed. I tried many things but in the end it comes down to the task not being updated while still queued via click on e.g. skip, despite being passed by reference as object.
I assume that this is not possible due to gradio queue for the generate button action.
It could also be possible to use an unique identifier per job and then update the task in the queue if it's not updatable via state, but i didn't go down that rabbit hole.

TL;DR: isolation works, stopping/skipping is possible only when processing started

Please merge or adjust if you think it's fine or have a different solution in mind, thanks :)

[mashb1t]

fyi this can also be empty, just to prevent future checks for e.g. processing or last_stop

[mashb1t]

@lllyasviel i've extracted all advanced_parameters to ctrls and added a PID based handling for class patch.py (overrides) to make it possible to separate the settings for each worker and job.
This not only could enable future parallelisation with multiple GPUs, but is also IMHO a clean way of user separation in Fooocus.

Skipping/stopping is now possible whenever you want, not only when processing.

Your feedback is welcome!

[mashb1t]

@lllyasviel i saw you just added

Fooocus/ldm_patched/modules/args_parser.py

Line 115 in 1bcbd65

parser.add_argument("--multi-user", action="store_true")

yesterday. Please re-evaluate this PR as it solves the need for global variables for advanced_parameters and removes them altogether. Thanks!

[patrickchamp]

As an iPad user, the browser page will often refresh when returning to the tab (low memory can’t keep it alive) which prevents me from stopping a task that was running before the refresh.

I’d like to somehow be able to stop the activity that I kicked off before the tab refresh. Since im the only remote user, being able to disable the queue isolation entirely would work for me. E.g. via command line arg. Or e.g. if it could allow queue cancellations originating from the same device.

Currently, to cancel the queue, I launch Remote Desktop on my iPad then close/restart fooocus. I can enter this as a feature request if that’s preferable.

[mashb1t]

@freshp124 I hope you can understand that this is by design so users don't cancel themselves when being in a multi-user environment and isolation was implemented to fix previous behavior.
Of course it's unfortunate that your browser tab automatically refreshes when reopening. Feel free to make a feature request, but it most likely is not going to be worked on soon, only if you or some community members assemble and form a team to inplement a PR.