Mumble Link tick rate and concurrent access about api-cdi HOT 9 CLOSED

It should be updated once/frame. The read-during-update issue is a known one and why I'm not particularly fond of using shared memory for IPC.

I can look into exposing a session-shared mutex. I'm not sure our platform abstraction layer provides that functionality, so no promises.

from api-cdi.

Paging @meh because I think he solved that problem on his NPAPI plugin.

from api-cdi.

@aRestless nope, it doesn't do any checks, just hopes for the best.

from api-cdi.

I can look into exposing a session-shared mutex. I'm not sure our platform abstraction layer provides that functionality, so no promises.

Thanks. That would be amazing.

from api-cdi.

Hm. To be honest I wouldn't throw resources at the MumbleLink protocol, but rather focus on an own, inherently thread-safe protocol for real time data that includes the same information. Additionally that mutex could potentially slow down the rendering process, especially if more than one external application would be accessing it.

from api-cdi.

that mutex could potentially slow down the rendering process

Only if the game client can't immediately acquire a lock and is programmed to wait for it. But it shouldn't wait. It should just fast-exit the update procedure if the mutex is already in use.

focus on an own, inherently thread-safe protocol for real time data that includes the same information

Yes please!

from api-cdi.

It should just fast-exit the update procedure if the mutex is already in use.

That can easily lead to starvation. Say my app and GW2 run at roughly the same fps/refresh rate, but my app runs a slight bit earlier than GW2. Then my app will always block GW2 from its update procedure.

Of course in reality there will be differences in runtime and the problem will only persist for short intervals but even then, would you really want that behaviour for real time data?

from api-cdi.

Per definition it's not real-time data if you have to wait to acquire a lock. And I think it's unreasonable for most apps to request an update at the same refresh rate as it gets written.

from api-cdi.

Not going to add a lock to the MumbleLink data -- my recommendation is that you handle exceptions due to mis-reads gracefully on the application side. Eventually I'd like to expose real-time data from the local client (e.g., via a websocket) but that's really really far off (read: after guild chat and character portraits).

Created a new issue for more accurate tracking.

from api-cdi.