Maybe users will employ LLMs to block ads? There's a problem in that local LLMs are less powerful and so would have a hard time blocking stealth ads crafted from a more powerful LLM, and would also add latency (remote LLMs add latency too, but the user may not want to pay double for that)
How can a parking_lot lock be less than 1 byte? does this uses unsafe?
Rust in general doesn't support bit-level objects unless you cast things to [u8] and do some shifts and masking manually (that is, like C), which of course is wildly unsafe for data structures with safety invariants
I don’t know the details of the Rust port but I don’t imagine the part that involves the two bits to require unsafe, other than in the ways that any locking algorithm dances with unsafety in Rust (ownership relies on locking algorithms being correct)
This is very similar to how Java's object monitors are implemented. In OpenJDK, the markWord uses two bits to describe the state of an Object's monitor (see markWord.hpp:55). On contention, the monitor is said to become inflated, which basically means revving up a heavier lock and knowing how to find it.
I'm a bit disappointed though, I assumed that you had a way of only using 2 bits of an object's memory somehow, but it seems like the lock takes a full byte?
It’s just that if you use the WTF::Lock class the. You get a full byte simply because the smallest possible size of a class instance in C++ is one byte.
But there’s a template mixing
thing you can use to get it to be two bits (you tell the mixin which byte to steal the two bits from and which two bits).
I suspend the same situation holds in the Rust port.
I am very familiar with how Java does locks. This is different. Look at the ParkingLot/parking_lot API. It lets you do much more than just locks, and there’s no direct equivalent of what Java VMs call the inflated or fat lock. The closest thing is the on demand created queue keyed by address.
>I am very familiar with how Java does locks. This is different. Look at the ParkingLot/parking_lot API. It lets you do much more than just locks, and there’s no direct equivalent of what Java VMs call the inflated or fat lock. The closest thing is the on demand created queue keyed by address.
Are you familiar with the new LightweightSynchronizer approach with an indirection via a table, instead of overwriting the markWord? I'd say that this has pushed the ParkingLot approach and Java's (Hotspot's, really) approach closer to each other than before. I think the table approach in Java could be encoded trivially into ParkingLot API, and the opposite maybe. Obviously the latter would be a lot more hamfisted.
The idea is that six bits in the byte are free to use as you wish. Of course you'll need to implement operations on those six bits as CAS loops (which nonetheless allow for any arbitrary RMW operation) to avoid interfering with the mutex state.
Unhelpful response. This cuongle.dev article does not answer nextaccountic's question, and neither do the webkit.org articles that describe the parking lot concept but not this Rust implementation. The correct answer appears to be that it's impossible: `parking_lot::RawMutex` has private storage that owns the entire byte and does not provide any accessor for the unused six bits.
(unless there's somewhere else in the crate that provides an accessor for this but that'd be a weird interface)
(or you just use transmute to "know" that it's one byte and which bits within the byte it actually cares about, but really don't do that)
(slightly more realistically, you could probably use the `parking_lot_core::park` portion of the implementation and build your own equivalent of `parking_lot::RawMutex` on top of it)
(or you send the `parking_lot` folks a PR to extend `parking_lot::RawMutex` with interface you want; it is open source after all)
> and neither do the webkit.org articles that describe the parking lot concept but not this Rust implementation
The WebKit post explicitly talks about how you just need two bits to describe the lock state.
> The correct answer appears to be that it's impossible: `parking_lot::RawMutex` has private storage that owns the entire byte and does not provide any accessor for the unused six bits.
Not impossible. One way to do this is to just use parking_lot directly.
In WebKit there’s a template mixin that lets you steal two bits for locking however you like. JavaScriptCore uses this to steal two bits from the indexing type byte (if I remember right)
> The WebKit post explicitly talks about how you just need two bits to describe the lock state.
It describes the algorithm but not how a caller of the Rust `parking_lot` crate could take advantage of this.
> Not impossible. One way to do this is to just use parking_lot directly.
By "just use parking_lot directly", I think you're talking about reimplementing the parking lot algorithm or using the C++ `WTF::ParkingLot` implementation? But not actually using the existing Rust crate called `parking_lot` described in the cuongle.dev article? That's confusingly put, and nextaccountic's question is certainly Rust-specific and likely expecting an answer relating to this particular crate. At the least, "does this use unsafe" would certainly be true with an implementation from scratch or when using FFI into C++.
I hear that this algorithm and the C++ implementation are your invention, and all due respect for that. I'm also hearing that you are not familiar with this Rust implementation. It does not offer the main benefit you're describing. `parking_lot::RawMutex` is a one-byte type; that six bits within it are unused is true but something callers can not take advantage of. Worse, `parking_lot::Mutex<InnerFoo>` in practice is often a full word larger than `InnerFoo` due to alignment padding. As such, there's little benefit over a simpler futex-based approach.
> It describes the algorithm but not how a caller of the Rust `parking_lot` crate could take advantage of this.
Read the WebKit post.
> By "just use parking_lot directly", I think you're talking about reimplementing the parking lot algorithm or using the C++ `WTF::ParkingLot` implementation? But not actually using the existing Rust crate called `parking_lot` described in the cuongle.dev article?
"just use parking_lot directly" is a weird way to say "use the `parking_lot_core` crate instead of the `parking_lot` crate".
...and note that I mentioned this in my earlier comment: (slightly more realistically, you could probably use the `parking_lot_core::park` portion of the implementation and build your own equivalent of `parking_lot::RawMutex` on top of it)
I'm not trying to be disagreeable here, but really you could save a lot of trouble if you were a bit more careful in your communication.
No. nextaccountic's comment and the cuongle.dev article are both talking about Rust. The Rust `parking_lot` implementation only uses two bits within a byte, but it doesn't provide a way for anything else to use the remaining six.
pizlonator's comments mention both the (C++) WTF::ParkingLot and the Rust `parking_lot`, and they don't answer nextaccountic's question about the latter.
> nextaccountic is confused.
nextaccountic asked how this idea could be applied to this Rust implementation. That's a perfectly reasonable question. pizlonator didn't know the anwer. That's perfectly reasonable too. Conscat suggested the article would be helpful; that was wrong.
The typical attack tries to get the victim to load a module which accesses information on the filesystem or in another module's memory, then exfiltrate that information using network access.
Other attacks may install backdoors used for infiltration once the service is deployed.
If the module provides some small helper function like `appendSmileEmoji(x: String) -> String` then it shouldn't be accessing the network or the filesystem, and the only memory it should have access to is the string passed into the function.
The programmer already provided enough information to explain to the compiler that the function should not do these things but poor language design allows them to happen anyways.
Components which do have access to the network should be vetted thoroughly because they can facilitate infiltration and exfiltration. Most supply chain attacks aren't introduced directly in a high profile project like a web framework, they are introduced deeper in the dependency chain in the long tail of transitively imported modules.
In Austral (or any language using these good ideas) a small poorly vetted function like `appendSmileEmoji` wouldn't be called with access to the filesystem or network. Without access to any resources, the worst it can do is append a frowning face or a null character or something annoying. You can tell by its function signature above, it doesn't take a capability for the network or filesystem, just a String.
So trying to ship a change that secretly accesses the filesystem would produce a "variable not found" error.
To even get the new version to compile, you would have to add an argument to take a filesystem capability. `appendSmileEmoji(x: String, fs: FS) -> String`.
That breaks any dependent modules because they have the wrong number of arguments, and looks very suspicious.
Does the following sounds like a joke to you? I mean, does passages like "I've always thought that under-populated countries in Africa are vastly UNDER-polluted, their air quality is probably vastly inefficiently low compared to Los Angeles or Mexico City" seem a joke?
And if it's a joke, what is the punchline?
DATE: December 12, 1991
TO: Distribution
FR: Lawrence H. Summers
Subject: GEP
'Dirty' Industries: Just between you and me, shouldn't the World Bank be encouraging MORE migration of the dirty industries to the LDCs [Least Developed Countries]? I can think of three reasons:
1) The measurements of the costs of health impairing pollution depends on the foregone earnings from increased morbidity and mortality. From this point of view a given amount of health impairing pollution should be done in the country with the lowest cost, which will be the country with the lowest wages. I think the economic logic behind dumping a load of toxic waste in the lowest wage country is impeccable and we should face up to that.
2) The costs of pollution are likely to be non-linear as the initial increments of pollution probably have very low cost. I've always thought that under-populated countries in Africa are vastly UNDER-polluted, their air quality is probably vastly inefficiently low compared to Los Angeles or Mexico City. Only the lamentable facts that so much pollution is generated by non-tradable industries (transport, electrical generation) and that the unit transport costs of solid waste are so high prevent world welfare enhancing trade in air pollution and waste.
3) The demand for a clean environment for aesthetic and health reasons is likely to have very high income elasticity. The concern over an agent that causes a one in a million change in the odds of prostrate[sic] cancer is obviously going to be much higher in a country where people survive to get prostrate[sic] cancer than in a country where under 5 mortality is 200 per thousand. Also, much of the concern over industrial atmosphere discharge is about visibility impairing particulates. These discharges may have very little direct health impact. Clearly trade in goods that embody aesthetic pollution concerns could be welfare enhancing. While production is mobile the consumption of pretty air is a non-tradable.
The problem with the arguments against all of these proposals for more pollution in LDCs (intrinsic rights to certain goods, moral reasons, social concerns, lack of adequate markets, etc.) could be turned around and used more or less effectively against every Bank proposal for liberalization.
> does passages like "I've always thought that under-populated countries in Africa are vastly UNDER-polluted, their air quality is probably vastly inefficiently low compared to Los Angeles or Mexico City" seem a joke?
> what is the punchline?
It's akin to saying "This establishment's high Google/Yelp ratings indicate it's leaving money on the table. There's clearly room to raise prices, cut costs, and really degrade the customer experience."
I don't know if Summers is telling the truth about his intent. But as far as jokes go, it's decent.
“A young healthy child well nursed, is, at a year old, a most delicious nourishing and wholesome food, whether stewed, roasted, baked, or boiled; and I make no doubt that it will equally serve in a fricassee, or a ragout.”
The whole thing is the punchline. If you're missing something, read strken's response elsewhere in this thread, because he put it in a better way than I have anywhere else here - none of it is serious, and if you read it seriously, you are the other punchline:
> argumentum ad absurdum indictment of the way the "cost" of pollution is calculated.
It's not a joke. He didn't even say it was a joke. He said (as quoted on the Wikipedia page for the memo!) that it was “a comment on a research paper that was being prepared by part of my staff at the World Bank” and that it “sought to clarify the strict economic logic by using some rather inflammatory language”.
The closest it gets to being a joke is that it is mockery and derision directed at underlings as a form of feedback on work product.
won't solidworks run on wine? i used it for just one semester in a class, but it sparks joy to this day. and even though it's not a cad program, i wish blender had parametric tools
I think that osh is valuable precisely because of that, since it's bash compatible. The project also has ysh which is not bash compatible, but fixes a lot of shell brokeness, including the #1 source of shell bugs, the need to quote almost 99% of variables and subshell invocations (and not quote them in the rare case you actually want splatting)
reply