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)
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)
