Spaces:

Omnibus-archive

/

Diffusion-Flood

like 5

Runtime error

gradio.State looks like it prevents multiple user images from contaminating each others results. I just ran 100 "tree" and 30 "fish" with no crossing of images like before.
I'll leave this Space up with your fix, because I like seeing it working as intended.
I'll further employ gradio.State rather than Global variables in any other Space I make that requires such function.
All that said, I'm not any less concerned about the ability of users to accidently code a page that allows anyone to see anyone else's input and output, but at least now, I can make well functioning Spaces.
Thanks for your help.

I see the new language in the Gradio Documentation, "and all users":

"Global State
Your function may use data that persists beyond a single function call. If the data is something accessible to all function calls and all users, you can create a variable outside the function call and access it inside the function. For example, you may load a large model outside the function and use it inside the function so that every function call does not need to reload the model."

Was this description added rather than just fixing the problem of user data crossing paths?
How many spaces are using "variables outside of function calls" expecting the variable to be reachable by all functions not, "all users".

Can you name some examples of why a Space variable should be reachable by "all users"?

@radames :

In you case , you were sharing a Global state across different users.

anzorq/finetuned_diffusion has the same issue. I experienced quite a few issues when duplicating that space and I believe at least some are associated with the use of global variables.

I would imagine that hundreds of pages before, and thousands to come will assume that a Global Variable is used Globally within the functions of the Python program, and not Globally for all users of Huggingface.

Can you name some examples of why a Space variable should be reachable by "all users"?

Many spaces just load one model and then let users do shit with that model.

This model needs to be loaded only once, when a space is started, and not afterwards. For this, global variables that are persistent for all instances run by all users make sense.

But when you have a space like yours, where you want each user to be able to hot-swap different models, it can get pretty messy. I found that out myself the hard way when duplicating anzorq/finetuned_diffusion and trying to modify the duplicated space.

In Huggingface Spaces this has the same effect:

variable=[]
def my_fn(input):
return variable.append(input)

This will append any users "input" to the same "variable", and then return the mixed "variable" to any and all of the users indiscriminately.

I rarely use the word "Global", but that word just means "use Globally within all functions of the program".
Simply setting a variable outside of a function call has caused user output to combine on at least 8 spaces, ranging in tasks from "video to frames", "2d to 3D Model", "2d to Depth", "text to image", "translation"

I've come to the conclusion that it's not me, it's them.
I shouldn't be able to accidently see other users output when I don't even know if it's possible to do that on purpose.

@Omnibus :

I agree that it's behavior that's unexpected, totally insecure and likely to result in lots of buggy code.

Yet I still understand why you'd want to have global variables that persist across all instances of all users, especially in an environment like this. It's much more efficient to just load a model once when an app is first run, rather than loading it every time a user runs a space. That is, for a typical use case where you just want to run one model and not allow users to hot-swap it.

However, I'd definitely argue global variables should be documented a hell of a lot better and it shouldn't be as easy as it is to use them incorrectly.

@johnslegers

I'm with you on the benefit of loading the models, pipelines, etc. one time when the space is built, rather than loading a model instance for each user.
I think the bug I'm seeing is when multiple users submit input to that model at the same time, the "where to send the output" function of HF Spaces gets confused, and everybody gets a grab bag of whatever the model was processing.

The Global variables of the space like "Global x" or "x = 10 (outside of a function call)" should load fresh with each user, and not be shared by users.
Something in the way Spaces are currently built allows user data to mix together, and fixing it might be as easy as assigning the users IP, MAC address, Phone ID, browser cookie to their inputs and outputs.