Poor design, flawed assumptions, manufacturing defects, inability to bear the gravitational and rocket launch forces, inability of the jacket to last the duration of the radiation exposure - these are some reasons that come to my mind on why a radiation-blocking vest wouldn't have worked for the journey to the moon and back (i.e. your question "Why wouldn't it?".)
"that the limited supply goes to the buyer who need it the most" - I would say that the limited supply goes to the buyer who can afford to pay higher than others. Someone may need the memory more, but may not have the deeper pockets to pay for it like NVidia and Apple might.
I would have framed it as "buyer who can get the most leverage from it", which equates to being able to spend more. It's an economic argument, not a values argument.
In JUnit, tests run sequentially in a single thread by default [1].
Parallel execution must be explicitly enabled. When enabled, JUnit uses a fork-join thread pool, so tests may run concurrently on different worker threads. Because these threads are reused, a ThreadLocal value left behind by one test could be visible to a later test that happens to run on the same thread.
Setup and teardown methods can be used to create and clean up test-specific state. However, developers must still ensure that test data is unique to the test so that concurrently running tests do not interfere with each other. This uniqueness is unfortunately called "isolated", and has led to much confusion like in this thread. Certainly, the Test Execution Framework cannot guarantee data-isolation.
Parallel and randomized test execution can also help expose application-side problems involving shared or order-dependent state. Such failures may only appear when tests happen to exercise the application under the relevant ordering or concurrency conditions. When I was a junior developer teaching myself Java Servlets in 2000, I had to learn this lesson the hard way. A Test Execution Framework would not be able to guarantee any "isolation" of test data and of workflows if the server-side state is mis-managed by the tech stack and/or by the developer.
> Parallel execution must be explicitly enabled. When enabled, JUnit uses a fork-join thread pool, so tests may run concurrently on different worker threads. Because these threads are reused, a ThreadLocal value left behind by one test could be visible to a later test that happens to run on the same thread.
I don't understand your comment. JUnit docs describe parallel execution as an experimental feature that still has gotchas that you need to be mindful to avoid. So you have a test framework designed with isolation in mind for a specific execution mode, but when you go out of your way to try another execution mode that is described as experimental then you can stumble upon very corner cases where isolation is not ensured. What point did you wanted to convey?
I disagree so hard with the notion that isolation is somehow done for you, that I don't even know how to begin arguing.
I'll admit to starting this confusion by reading what I thought would be written, not what was actually there. TFA does phrase it to my satisfaction that the test is isolated. I assumed when reading it that Kent thought he had isolation but did not. By analogies: a naive programmer does not perceive the existence of race conditions; a naive web app developer doesn't perceive the existence of CAP; a naive backend engineer thinks they have full ACID guarantees when they're only guaranteed READ_COMMITTED. I thought I was reading another writer just wishing isolation into existence through ignorance.
(So I accidentally straw-manned Kent's argument, but maybe that's not such a problem, because it seems you're OK with the straw man version?)
Anyway, maybe a question moves things forward.
JUnit's been around for decades. Every developer has had multicore dev machines for decades. Why would parallel execution not be the default, or a simple toggle that everyone would turn on immediately?
I anticipate some kind of futures on GPUs based on a number of factors such as the availability for rent, the availability at your marketplace, and the models currently available for self-hosting.
Yes, those types of differences across different providers is what the finance world calls basis risk. As more and more transactions take place, we hope to bring transparency into how different components/specs can change pricing, and make them tradable too.
Basis risk is also a big part of futures markets, how much does spot price differ from forward pricing and why. For physical GPUs, theory would expect a downward sloping forward curve due to the depreciation factor, but from what we have seen recently, sometimes not the case!
reply