// 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
In all other cases, the memory is either thread-local write-local or followed up by an indirect aquire/release of the processors pipeline and L1 cache by virtue of the containers dumb spinlock ::Lock, ::Unlock (...release, ...barrier)
Clang doesn't have /volatile:ms anymore so we cant rely on that
Assuming MSVC-like or x86 isnt good enough
(and, no retard midwits, volatile is a fine keyword. take ur spec sperging and shove it. i just need to control over-optimization of defacto-weakly ordered access between explicit lockless semaphore yields)
Even worse, im just going to fucking nuke all clang related checks from orbit in our global build_scripts (8b00dc69fceea62ecbbf5a21255a41e2f23921a4), because they admit they cause a 2x slowdown.
Unrelated note, Windows XP does in fact have NLS support with these APIs; we just need to use "nlsdl.dll". Fortunately, we already have Windows XP paths, and that DLL is nothing more than a 24kb stub that calls GetLocaleInfoW. Something we already do ourselves.
03:28:55:638 17>2 of 53388 functions (<0.1%) were compiled, the rest were copied from previous compilation.
03:28:55:638 17> 0 functions were new in current compilation
03:28:55:638 17> 65 functions had inline decision re-evaluated but remain unchanged
03:28:56:749 17>Finished generating code
the header of const AuString & is the same as std::string_view therefore nothing changes. in fact, we still need to alloc strings a bunch of times for a zero terminated string. worse, <c++20 always allocs each time we want to access a hashmap with o(1) lookup, making small hashmaps kinda pointless when we always have to alloc+copy (thx std)
perhaps this will help some language binders
[*] Rework/Fix WELL_NextBytes (large) improperly accounting for small buffers (this internal function is publicly visible. WELL_NextLong isn't going to save us)
