Hey, fellow hardware hacker!
I used Dash a few months ago to build a web interface to several modems in our lab, and overall I found it to be a marvelous framework for interacting with a piece of hardware.
These programs necessarily need to use some kind of global instance for Dash to interact with.
This was true in my case too. The inputs received from the GUI need to be translated to the appropriate opcode and sent to the equipment via serial port. Only one process can bind to that port at a time, though, and I was a little unsure after reading the docs whether an application’s callback functions (which may run on a different thread than the main application) would play nicely with a shared, mutual resource.
It worked pretty well! I did protect mutable objects with a
multithreading.Rlock semaphore to ensure thread safety, but I’m not sure it’s necessary.
For my purposes, I’ll probably limit things to just 1 connected user somehow, but it’s limiting, and there are other possible solutions. I’m wondering if the Dash developers and/or community are addressing this.
I’m not sure what your ideal control flow looks like, but I’ll share with you some implementation details that might be helpful. I opted to disregard several warnings in the documentation about writing to global variables, because it wasn’t particularly important to me that multiple people be able to interact with the hardware at the same time. Consequently the application state behaves almost identically to hardware state… meaning, basically, that if you configure it one way, then close the tab and navigate back to the page, it’ll be exactly the same as before.
I suspect the app would probably work with multiple users, just because I know that the way I structured my callback (of which there’s only one) it’s listening for state changes to any mutable property of the GUI. So then any time there’s a state update, the entire state of the GUI is sent to the server along with it in the POST request, and the application’s backend state is always synchronized with the interface that changed most recently. So in theory, it would probably work, sort of, but the modem would just oscillate between two completely different configuration profiles depending on which user most recently modified an input field.