Added Bunnysplit MQ for Linux

[chinese-soup]

Just doing my part for the Linux gaming. :^)

As discussed on Discord, basically just 1:1 to Windows. 1:1 to TASView mq, except O_NONBLOCK since it's always enabled as opposed to TASView's (i.e. no reader = blocking game process when bxt_interprocess_enable is 1).

Tested it on my NIH syndrome split timer implementation, it worked fine during the development so far.
I plan to release that ^ split timer once I'm happy enough with it and later plan to also implement an autosplitter for it to LiveSplit One/LSCore.

[YaLTeR]

What happens if there's no client to read from the message queue? The tasview one will block once it exhausts the buffer, but what happens with the bunnysplit one? Does it start erroring and recreating the message queue every few seconds? If so, doesn't that cause lag? Most of the time there's no bunnysplit on linux so that's why I'm wondering, that situation shouldn't regress.

[YaLTeR]

Can you extract variable on the std::chrono::milliseconds(static_cast<long long>(1000 / CVars::_bxt_bunnysplit_time_update_frequency.GetFloat()))?

[chinese-soup]

What happens if there's no client to read from the message queue? The tasview one will block once it exhausts the buffer, but what happens with the bunnysplit one? Does it start erroring and recreating the message queue every few seconds? If so, doesn't that cause lag? Most of the time there's no bunnysplit on linux so that's why I'm wondering, that situation shouldn't regress.

Uhh, isn't this already answered in the OP? And no, it doesn't restart the message queue every few seconds.

[chinese-soup]

Can you extract variable on the std::chrono::milliseconds(static_cast<long long>(1000 / CVars::_bxt_bunnysplit_time_update_frequency.GetFloat()))?

Done. Couldn't extract the whole std::chrono::milisecond call without doubling code, because then I wouldn't be able to add + 1 to it in static auto last_time = //...

Should I backport it to the Windows version too?

[YaLTeR]

Uhh, isn't this already answered in the OP? And no, it doesn't restart the message queue every few seconds.

Well I still don't understand what happens when there's no reader then? Do the messages get dropped or what happens?

Couldn't extract the whole std::chrono::milisecond call without doubling code, because then I wouldn't be able to add + 1 to it in static auto last_time = //...

Now that you extracted it I can actually see there's a + 1 there that I missed before, heh.

Should I backport it to the Windows version too?

Sure.

[chinese-soup]

Now that you extracted it I can actually see there's a + 1 there that I missed before, heh.

Same tbh, so optimized for humans now 👍

Well I still don't understand what happens when there's no reader then? Do the messages get dropped or what happens?

Ah right, my bad, no idea how I didn't notice it before, lol, so yeah, you are correct in the fact that currently it keeps on retrying to do mq_send and closes and opens the message queue, every time that WriteBunnySplit is called (which most of the time is when _bxt_bunnysplit_time_update_frequency is hit in WriteTime)

How would do you want me to solve this? Should it just fail (close the queue) and not reopen it automatically and only reopen it when _bxt_interprocess_reset is manually entered in the game console?

Sure.

Alright, will do.

[YaLTeR]

How would do you want me to solve this? Should it just fail (close the queue) and not reopen it automatically and only reopen it when _bxt_interprocess_reset is manually entered in the game console?

Yeah idk this stuff is complicated, let's go with the "only reopen it when _bxt_interprocess_reset" solution for now