I think that specific issue was a huge mistake, because it means the interruption, which was already messy, is now unusable.
First, you can get deadlocks as interrupt now calls arbitrary code to close channels. Second the interruptee thread cannot recover from an interrupt, if it chooses to to. Lastly it means that a server that shares a file descriptor with multiple threads breaks unrelated operations on interruption.
The first is, annoyingly, a relatively common problem and solution when dealing with GC lifetimes in tests. Few interpreters/JITs want to generate extra instructions to null out stack slots or pre clobber registers to ensure something becomes collectible at a specific point. Eager nulling of a variable often gets removed by dead store elimination or even just from being a disconnected SSA node. I've written extra nested scopes or wrappers in Java to deal with this in tests.
If this is needed in tests it needs to be known how it works, it needs to work consistently, and it needs to be documented how it works. It can't be an ad-hoc deep investigation and random fix each time. The comment should then be just // ensure foo is no longer a GC root, see gc_roots.md
They were not serious about their sandboxing. Bugs in artifactory allowed escape, but they broke out of their Linux namespace/user by exploiting the kernel with an existing public cve. Sharing a kernel like that is not a serious barrier which is why cloud providers user virtualization for customer workloads.
Firecracker avoids sharing the whole kernel, and gvisor drastically reduces the attack surface of the kernel. Breaking through both layers would have been much more challenging and a demonstration of the model's capabilities rather than the sandbox's weakness.
Artifactory is self evidently not a security barrier, and as an exposed network service it should have been audited and after the first issues were found, rejected as a candidate. There's never just one security vulnerability.
And if you want to write a templated data structure without actual templating or fancy macros, doing so with force-iined functions calling function pointers that are constant at the call site is a great way to do it. Unfortunately it's ugly and annoying to do this without nested functions :-/
>today you could set up a system where the whole process is tap two phones together with nfc and confirm
This was actually possible in 2011 or so, and a friend and I implemented it for a school project. How well the ux works depends on whether you want to use a key exchange protocol for the in person communication.
A weather widget using 8 bit color plus alpha on a 4k display show three full size images in 100mb. But I suspect that's not the ux we're talking about here, and a widget style system has no excuse.
Apple's Weather app has an animated background, glassy views, and nice animations like water droplets on the glassy views when it's raining. So rendering all that on a 4k or more display at 10bit depth is going to consume a bit of RAM. However I guess it can surely be improved to make it consume less RAM.
The display on that page is literally broken for me, the boxes are all misaligned. It seems like it can't handle Japanese text correctly. Properly working localization in dozens of languages is one of those things that adds "bloat" to modern software that was missing in the bad old days.
From a hardware perspective this is correct. From a language perspective it's UB, and unless your compiler has defined that UB, it doesn't matter what the hardware's behavior is unless you're writing assembly.
So you're saying the problem that this article is solving is just preventing the language from generating code that can possibly load some incorrect bytes from main memory, even though these incorrect bytes will in every case be ignored? Why is this considered a problem at all?
It's a problem for language specifiers, basically. The behavior is undefined in the standard; to rely on it you either need your implementation of the standard to define it themselves, or you need to bet that there is no possible sequence of machine instructions the compiler could emit that would implement the defined behavior in a way where a data race would do something harmful.
As far as I know there is no reasonable compiler that wasn't specifically trying to add some kind of sanitizer that would emit anything other than plain memory reads, but it would be nice to not have to worry. But sanitizers are handy! I can imagine some sanitizer implementation forgoing extra internal synchronization that would only be needed in the case of program UB anyway.
This is overstated in value; on arm systems with LSE it's faster to use that even for weak operations than to use ll/sc. Even if you are limited to ll/sc the compiler may not put your cas-loop body into the ll/sc region as there's limitations on how many and what type of instructions are permitted there.
On ARM systems with LSE both weak and strong compile to the same CAS instruction anyway. On LL/SC, using strong means CPU will attempt to retry the same exchange on spurious failure, which increases likelihood that another thread will update the value in the meantime, requiring an outer loop retry.
On any plaform which implements strong exchange with zero overhead over weak exchange, we can safely assume they compile to the same thing, and use weak. The only reason to use `strong` is if you have a one-shot CAS operation and you don't want to write a retry loop.
Sure, with LSE. But you have to target LSE and get a system that actually contains it, i.e. not the default compiler flags and not the original AWS Graviton.
reply