You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only thing I found really annoying is the amount of times that PAMAC locks with lock_file since pylamp also has its own lock. I propose to change its blockade by a multi-thread environment where threads lock in the daemon when some client access to danger zones.
This will give you the ease of graphical interface completely separate business, giving greater flexibility to the application.
In a multithreaded enviroment, the thread started by client notifies the thread that is waiting for data (possibly confirmation of a transition).
I currently make this for my application, but in my application only use a subset of pamac... Clear will be more complex for pamac. When i can test that all is working, i will try to add this to pamac, but i think will be better have this in a non master branch for some time, to be tested first... Have dependency of a daemon with multithread, could create several test cases...
The only thing I found really annoying is the amount of times that PAMAC locks with lock_file since pylamp also has its own lock. I propose to change its blockade by a multi-thread environment where threads lock in the daemon when some client access to danger zones.
This will give you the ease of graphical interface completely separate business, giving greater flexibility to the application.
In a multithreaded enviroment, the thread started by client notifies the thread that is waiting for data (possibly confirmation of a transition).
The text was updated successfully, but these errors were encountered: