Re: [Srcpd-devel] Locking one GL locks all GL

[Simon A. <sim...@gm...>]

Alright, looks like I got it working. GL locking is now glstate-based in my
local copy and timed locking of GLs is working.

Is anybody interested in the changes, as simple as they may be? Has anybody
been working towards a 2.1.6?

Best regards,
Simon

On Tue, Feb 23, 2021 at 8:44 PM Simon Ahrens <sim...@gm...>
wrote:

> Oh... sorry, I think I see what you mean about the bus level... it's
> missing all/most of the address specific references a la ".gastate[addr]".
> Alright... I'll dig deeper in the next weeks :)
>
> 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
>>
>