// Even if clang (and gcc) has these intrins available, you must enable them globally, unlike see for some fucking reason.
// I mean, we can do runtime branching around SSE4 paths no problem. Why all of a sudden am i being gated out of the intrins im electing to use by hand?
// No, you (the compiler) may not use these in your baseline feature set (or incl in stl locks). Yes, i still want them. Now fuck off.
// If these end up being wrong, blame clang and gnu for being cunts, not me.
No, I will not raise our requirements above ivybridge; no, I will not expose feature macros to the STL (et al) that boosts our requirements to modern intelaviv slop and amd atomic ackers
This is required for Xbox, Xbox 360, and Win32 emulators deriving a mutex via a the NT semaphore primitive instead of the builtin binary semaphore (event) and mutex.
This is the dude tasked with managing Linshits IO stack, including the fundamentally flawed muh zero-syscall pissring (#a), the fucked io_submit apis that never worked properly (incl io_cancel that spuriously returns EINVAL despite all magics matching); the retard who stuck to Linus's idea that MUH O_DIRECT IS LE EVIL YOU MUST USE MY CACHES REEE REEE (#b); and the retard who got indirectly called out by Linus as being apart of the database maintainers who Linus didn't/doesnt like and who wanted these APIs in the first place (#c).
#a
This dumb cunt can't even write a ring buffer. He thinks the solution to everything is spawn a thread, like the glibc and libuv retards.
He seems to think a ring buffer also magically hooks into a thread scheduler, and something something, orange lingo, muh zero syscall overhead as if the kernel should be/is constantly checking every thread for an arbitrary amount of IO ring buffers.
#b
"The whole notion of "direct IO" is totally braindamaged. Just say no.
This is your brain: O
This is your brain on O_DIRECT: .
Any questions?
I should have fought back harder. There really is no valid reason for EVER
using O_DIRECT. You need a buffer whatever IO you do, and it might as well
be the page cache. There are better ways to control the page cache than
play games and think that a page cache isn't necessary.
So don't use O_DIRECT."
- Commie Torbals, maintainer of toy academic kernels
#c
"AIO is a horrible ad-hoc design, with the main excuse being "other, less gifted people, made that design, and we are implementing it for compatibility because database people - who seldom have any shred of taste - actually use it". But AIO was always really really ugly."
- Commie Torbals, maintainer of toy academic kernels
"Jens works for Oracle"
- https://web.archive.org/web/20130402030321/https://events.linuxfoundation.org/jls06b
And that's not to mention Google and NodeJS has disabled the usage of his pissring implementation because of shit like this. His shit code has been and will continue to be a security risk. I can't blame them. This retard mustn't be trusted with so much as an 8 year olds lemonade stand.
[*] Fix: IO objects not using the explicit slow sync primitives.
Dunno how these werent refactored; then again, i never properly got around to finishing the factories for fast/slow io objects. In addition, some of these arent even accessed by the ILoopSource interface, so it's not as critical of a failure.
[+] AuMemory::HeapAdapterInterface to describe aforementioned heap allocators of a very limited API
[+] AuMemory::HeapAdapter[Unique,Shared,]
[+] HeapWin32Adapter to convert HANDLE hHeaps of win32s CreateHeap (RtlCreateHeap?) into AuMemory::Heaps
(sure, it cannot work to realign structs with c++ operator[] overloading; however, we need this to prevent excessive allocations when cloning a U8 memory view of alignment)
