I'm author of Meshbird. Big different between Tinc and Meshbird. When you start Tinc you have to specify other node addresses. When you start Meshbird you have to specify network secret key only. Meshbird's node will find each others automaticly.
Overhead of std::mutex depends a lot on contention patterns. Assuming one x86 CPU socket, usually you can take + release an ideally optimized contended mutex about 10M-25M times per second, if that's all you do, 100% CPU usage on all cores. That's simply limited by how many times you can run contested LOCK XADD (x86 atomic fetch-and-add) / LOCK CMPXCHG* (x86 atomic compare-and-swap) instructions per second.
Mutex generates a lot of cache coherency traffic and saturates the CPU internal ring bus. NUMA case it'll of course quickly saturate lower bandwidth CPU external QPI link(s).
Contested mutexes perform a lot better on a typical laptop than on a server.
OK, now I see what you are saying. It would certainly be true for a spin lock, but it seems to me that, for std::mutex, the kernel transition required to arbitrate contention would dominate even on the coherency traffic, right?
You're right that context switches would dominate std::mutex. For some reason I was thinking std::mutex uses spinlocks, even though I knew better. Too much kernel side coding lately - context switches are often not possible there, so mutexes are often not possible as potential synchronization mechanisms.
You might still be right. The implementation of std::mutex is unspecified, and real world implementations will probably spin a bit before going into the kernel, so for your test case with a tiny critical section it might behave like a spinlock.
I recall hearing/reading that there are sections of the standard which mostly suggest that a tree is the only valid map data structure. I think something to do with iterators and was mentioned in a CppCon talk or blog article. I will try to dig this up.
There is no fundamental reason why native apps can not expose shareable links just like any other. And on the other hand with the prevalence of single page webapps etc its far from guaranteed that you can get usable links from webapps.
A web link is easily shareable on the assumption that anyone you send it to has a web browser. A link to a native app requires you to assume that the recipient has the app installed and is on a platform where app URL schemes are well-supported.
Direct linking inside apps has been enough of a pain in the mobile world that entire companies have been built around it -- and the solution that those companies tend to use is built on web links. Android and iOS have also been moving in that direction.
None of them are great. Android and very recent iOS are doing OK. Desktop OSes are still pretty bad. Clicking a non-HTTP protocol link in Chrome pops up a huge, user-unfriendly "External Protocol Request" dialog that warns of a possible attack on my system. That's pretty par for the course for desktop browsers.
Pretty poor, right now, unfortunately. I was looking at replacing VMWare Workstation with Hyper-V. However, when I installed Ubuntu Desktop on a brand new Hyper-V VM, I had to do some grub hacking to pass kernel parameters to get the display resolution right. Even after I got the display resolution right, there was a noticeable lag in the GUI refresh. I know that maybe with some more hacking I could have gotten everything to work just as well as it does on VMWare Workstation, but that proves my point. In VMWare, everything Just Works, out of the box. In Hyper-V, you need to tweak things to to work, and it's not clear what all things you need to tweak.
Allegedly that will be improving with Windows Server 2016, which is supposed to have better support for GPU acceleration for VM guests, but I'm waiting to see what actually gets delivered before I get excited.
This might not be the answer you like, but for "serious" fighter jet simulators there is pretty much two options, both of them Windows only.
There is still a community around Falcon 4.0 keeping it on life-support. But I wouldn't really recommend it as a starting point, considering the significant effort it takes just to get it up and running.
The other alternative, more modern and my recommendation, is DCS family. It consits of (gratis) core DCS "World" engine, and a selection of (paid) add-on modules (=planes etc). The nice thing about it is that you can just download DCS: World to try it out, it includes two planes you can fly. The not so nice aspect is that it is quite heavy, both in terms of hardware requirements and in terms of gameplay/learning curve. Its very much jumping to the deep end.