Coroutine vs filewatcher

[axvm]

Hi

Is there any reason why you using coroutine in cycle instread of FileSystemWatcher Class? https://github.com/dantman/elite-vr-cockpit/blob/1d7a8c2d128a8c9ca76cf4cb2324ef89beece595/Assets/Scripts/EDStateManager.cs#L235

https://github.com/dantman/elite-vr-cockpit/blob/1d7a8c2d128a8c9ca76cf4cb2324ef89beece595/Assets/Scripts/EDStateManager.cs#L302-L344

Im not c# developer but as far as i can understand the code, it reading (allocating memory, opens file descriptor, reading file to memory) and then checking if something changed. It may be possible cause of memory leak, isn't it?

[dantman]

Normally commands like ReadAllText that don't work with a file descriptor create their own file descriptor and close it themselves. So they shouldn't leak.

A few things worth noting:

• Coroutines keep you in sync with the update loop, so you aren't triggering things at different times of the frame making flickering bugs even more likely. Even if I use the watcher, I'll probably end up spawning a one-off coroutine on each change just to make sure it happens at the same frame timing each time.
• ED updates the Status.json every few seconds. So even if I use a watcher the overlay will still be reading the Status.json frequently. The only difference will be that the file isn't read unnecessarily every now and I also have to spawn extra coroutines to sync things up.
• And generally watchers aren't 100% reliable, though I suppose the usual culprits like network filesystems and other special environments that break watchers aren't relevant in this situation.

[axvm]

@dantman thank you for clarification. I'm just trying to figure out the reason of frps drops in my system. Some times after running ED+vr cockpit for a while(2-3 hours active gaming in a row) fps drops to 30-40 frames and returns to normal values after 10-15 mins. It happens only when Im using vr cockpit. Looks like i need to find the way to run cockpit in debugger...

[dantman]

On the other hand. There is a slight possibility that using a file watcher might reduce the lag in cockpit changes. e.g. Make the cockpit interface disappear faster when the galaxy map opens. Of course, that's only if ED writes to the Status.json fast enough.

[flavourous]

For what it's worth, I did some testing. Making the coroutine run a lot hotter (0.1s realtime), and using FileShare.ReadWrite to avoid io conflicts, and then pinging "Key_1" (my panel binding) every few seconds, logging the delta between the keypress and detecting the GuiFocus in the status.json coroutine.

https://github.com/flavourous/elite-vr-cockpit/tree/test/guifocus https://docs.google.com/spreadsheets/d/17iL9BNszqTVHy-hteCoJ43htUTeJDDzLNfP9m_fJ8qE

[dantman]

The clumps/lines could be artifacts of the slow 100ms sample rate and the rate that ED updates status being different.

Making the coroutine run a lot hotter (0.1s realtime)

😆That's not much hotter, 0.1s is 100ms. VR frame timing is 11ms. And even 30fps is only 33.3...ms.

and using FileShare.ReadWrite to avoid io conflicts

That will only stop the unlikely IO conflicts where ED tries to write during the moment we read.

You'll still be getting the more common IO conflicts where we read while ED is trying to write.

Run time

Is this how long things were running for?

[flavourous]

The clumps/lines could be artifacts of the slow 100ms sample rate

There are around 10-20 reads of status.json between (well, a lot at least) each datapoint there. Each datapoint is a successfully read status.json. So I'm not sure about that explanation...the sawtoothing is definitly odd though.

That's not much hotter,

Yeah, tried 100fps, but it seemed excessive given the read rate as mentioned above

You'll still be getting the more common IO conflicts where we read while ED is trying to write.

Don't think I got any conflicts, I can check that though. No errors parsing the json, but can check that too, could be picking up empty file while ED does Truncate-Write-Flush or something. I belive that FileShare.ReadWrite is going to totally remove the possiblity of a conflict - but not of reading (or god forbid writing if we both were) garbled data.

Is this how long things were running for?

Yeah that's the elapsed time on the stopwatch I'm using. Datapoints all come just before GUIFlags changed event gets raised.

[dantman]

You'll still be getting the more common IO conflicts where we read while ED is trying to write.

Don't think I got any conflicts, I can check that though. No errors parsing the json, but can check that too, could be picking up empty file while ED does Truncate-Write-Flush or something. I belive that FileShare.ReadWrite is going to totally remove the possiblity of a conflict - but not of reading (or god forbid writing if we both were) garbled data.

The IO conflicts with ED don't result in JSON parsing errors. Reading while ED is writing happens regularly and it results in an IOException. That's why the read/parse block is wrapped in a try/catch that ignores IOExceptions. You could change catch (IOException) to catch (IOException e)and throw aUnityEngine .Debug.LogWarning(e);` into the block and you'll see how often you get conflicts.

FileShare.ReadWrite will not remove the possibility of a conflict. That flag only stops YOU from locking the file while you're reading it. It does NOT stop ED from locking the file while it is writing to it. Which results in an IOException.