Feature Request: Low latency side channel for CD data

[Slamy]

The MiSTer service has a certain flaw when it comes to real time requirements for CD based machines.

Inserting/removing USB gamepads or doing screenshots disrupts the data flow and needs special handling in the core for an event that doesn't exist on real hardware. The PSX core is performing a full stop to fix this. For the CD-i core I'm not yet sure how this can be fixed or which type of workaround should be applied.

I'm adding this issue because I think that there might be someone out there who maybe knows a better way of handling this.
In theory it might be possible to add another thread to MiSTer Main which does only I/O.

[birdybro]

I think @zakk4223 has discussed this before here and in the discord, he's very informed on the possibilities of this.

[zakk4223]

It would be a significant change to Main and the framework. I'm pretty sure the fpga<->hps communication channel is not thread safe, so you'd have to create another one (if that's even possible) and then restructure all of main to use it.

There's a lot of 'cross contamination' in the various subsystems in main, so it might be tricky to do something like pull one of them out into a thread without introducing a bunch of complex thread synchronization. My gut tells me it would be easier to split off the disk i/o, but that's just a feeling based on 'it would be very complex to break out the input side'.

The screenshot thing is probably immediately fixable, that can be offloaded to the other core/thread without any impact, it's just writing stuff to disk.

I do want to add this though: even if this sort of re-architecture happened it does not solve the problem, it just makes it less likely. The linux side is NOT a real time operating system, you cannot rely on it to return data within X time. There's always a possibility it can get stalled due to various conditions in the kernel itself. Are you likely to get data back in a timely (whatever that means) fashion? Yes. Should you rely on that always being the case? Probably not. Does some of the design of main "artificially" create some stalls? Yes.

Honestly Robert's solution is probably the best. It absorbs any small deviations in i/o latency without much impact but makes it painfully obvious to the user something is wrong when the average latency is too high. Unfortunately it requires the entire core be pauseable