From: Simon A. <sim...@gm...> - 2021-02-23 19:36:48
|
I see, thanks for your answer. I noticed that timed locks for GL don't seem to work either - they always return 0 seconds. I'm currently writing a client application and easy multi client "cooperative" control is a priority for me. The lock features, in my opinion, are a really neat feature for that. Granted, GA locks probably a bit more so than GL locks. Still, I'll look into the srcpd source code and see if I might be able to fix that. At first glance the GL locks don't seem to do much different from the GA locks... can you give me a hint on what you mean by "GL device locks are implemented on bus level"? Looks like handle_setcheck(...) calls lockGA(...) for GA and cacheLockGL(...) for GL... and those functions - at first glance - look rather similar? Sorry - this is only the second time I've looked into the sources... Thanks again and best regards, Simon On Tue, Feb 23, 2021 at 7:39 PM Guido Scholz <gui...@gm...> wrote: > Am 23.02.21 um 17:03 schrieb Simon Ahrens: > > Dear all, > > Hi Simon, > > Now I've stumbled upon an issue locking GLs that I hope you can help me > with: Whenever I try to lock one GL, the server seems to lock all GL but > without sending 100 INFO messages about it. Here is what's happening > (locking from session ID 887): > > [...] > > The server is running srcpd 2.1.3. Can you explain this behaviour? It > seems to be working as I'd expect for GA devices, by the way (lock one, the > others remain unlocked). > > Locks are not heavily tested. I don't know if there is any SRCP client > which supports this feature. > > Having just a quick glance at the source code I found regarding the GL > devices locks are implemeted on bus level. I have no clue if this is > intended or not, but I guess this is an error. > > Guido > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > |