Mumble Link tick rate and concurrent access

[sliekens]

I'd like to know how often the game client dumps its state to the Mumble Link shared memory block. I measured it to be around every 30 ms, but I'd like an official statement.

I'm asking because we're seeing cases where the update happens as we're trying to read from the memory block. In very exceptional cases, we end up reading a partially updated json string that crashes our json deserializer.

Would it be possible to update the game client so that it uses a named mutex object?

• https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/windows/desktop/ms682418(v=vs.85).aspx

Then we can update our code to use the same named mutex for synchronization.

[lye]

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.

[aRestless]

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

[meh]

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

[sliekens]

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.

[aRestless]

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.

[sliekens]

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!

[aRestless]

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?

[sliekens]

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.

[lye]

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.