A new futex API
lwn.net
lwn.net
This is not intended as a comment on LWN's subscription setup or the article or anything actually relevant. I'm just feeling a bit depressed at the state of funding-of-good-things. It sucks that it's so hard.
Personally, I pay for "project leader" level ($16.00/month) so I can give them a bit more... But I'm not up to "maniacal supporer" ($50.00/month)!
It seems to me that introducing morality into the discussion is overcomplicating it. I don't feel I have any moral obligations with the people I trade with, beyond not deceiving them.
To me, all those subscriptions have a management overhead that's often greater than their sticker price. Here, $30/month is actually better than $3/month, because there's only so many $30 things that will fit into my "I like it but it's not a strit necessity" monthly budget. But that same budget will fit 10x as many $3/month subscriptions, and the amount is small enough that it's easy to ignore, and it's easy to lose track of all such subscriptions (and then tracking them down and re-evaluating whether you need them feels like more effort per subscription than that $3 or $1 or whatever).
The bigger overhead, however, is relationships. Each subscription is a business relationship, and one I do not want to have. This is where the tax angle, and aforementioned symmetry with one-time purchases, would come into play: for regular one-time payments for goods and services, I do not need to establish ongoing relationships with the providers, because government does it for me. It rolls them all into a neat package by means of generic consumer protection laws, which allow me to not care or remember about any particular vendor if all is right, and if something goes wrong, all I need is to have a standard proof of purchase (receipt or invoice), and a set of standard keywords to put into an e-mail ("warranty", "non-compliant goods", "GDPR", etc.), and things magically right themselves most of the time. Worst case, I need to also remember which form to fill to get courts involved.
That's such a huge win, that most people don't even see it. Whenever you go to buy your daily bread, or get a haircut, you do not need to stick to the same vendor, or sign a contract with them, or otherwise care about ongoing relationship. You can, if you want, but you do not have to, and that's despite the vendor very much wanting you to. The relationship exists, but it's managed for you, centrally, by your local regulator - making purchases O(1) with respect to number of vendors. Whether you shop at one place or a thousand, the overhead is the same.
I would like that to extend to recurring services too. There is absolutely no need for a random SaaS to force me into having a relationship with them. I would prefer to have a standardized process of billing and resolving disputes that lets avoid having to study everyone's individual ToS, or dealing with vendors' dark pattern bullshit. I want to focus on making use of the service, not on who provides it. That's the symmetry rolling subscriptions into tax system would provide.
In Australia we’re getting a new system called “PayTo” which will be replacing all current direct debits. One of the advantages of this new system is that you can do precisely this-manage direct debits from within your bank account. Other benefits include making it easier to setup than the current direct-debit-tire-fire.
Obviously doesn’t help in all scenarios, as many subscriptions are just withdrawals, but it’s nice that it’s at least possible.
Like many google things touching payments, it unfortunately started in such limited area that it couldn't have any future other than cancellation for lack of interest, because most interested people couldn't use it...
This seems to miss out on the difference between commodity and non-commodity goods and services.
LWN, or the channels I watch on YT, or the people I support on Patreon, are not commodity services. They are not interchangeable in any real sense.
It doesn't, it applies to non-commodities too. Wanting a particular good or service != wanting an ongoing relationship with a vendor.
Even with YouTube producers, when I like some particular ones and support them on Patreon, that still doesn't mean I necessarily want a generic relationship with them as a vendor/brand - I may be interested in their channel, and everything they do around it, but that doesn't mean I want to hear about their other channel, or know about other unrelated businesses they run.
That doesn't also mean I never want such relationship either. I don't want it by default, and I want to control how far I go, not be tricked or dragged into what I do not want.
> Whenever you go to buy your daily bread, or get a haircut, you do not need to stick to the same vendor
This is absolutely not possible with non-commodities. If you want that YT producer's stuff, you have to go to them. You cannot switch to another "vendor".
> or sign a contract with them, or otherwise care about ongoing relationship
Well, that's certainly true, but I'm not sure what it really means given that you cannot switch suppliers.
However, my point is focused more on the relationship aspect. Even with a 100% unique, non-commodity creator, to whom I have to go to get my content fix, there's a difference between two scenarios:
- I come if and when I want, consume content and/or support them in exchange for specific content, or as generic patronage - but otherwise, they do not force themselves into my mental space.
- Like above, except I get spammed by the creator, especially with marketing material outside of what I care about; I have to remember to manage recurring payments 'lest I'll be unknowingly spending money on things I don't want; subjecting myself to the above is a de-facto condition to access the content I want.
The ideal non-commodity recurring relation for me is almost purely transactional - I pay and get what I want in exchange, and nothing more, and otherwise can safely forget the vendor exists.
NetBSD and Windows seemed to have made a more perf-flexible API here: Each thread has an implicit AutoResetEvent which it can wait on while any other thread can set it. All task queueing can then be done in userspace, in a lock-free fashion too for Windows. This avoids that extra syscall at the end for futex based locks/rwlocks and employs natural/efficient requeue. NetBSD has a slight edge in that you can set the AutoResetEvent of multiple threads using a single syscall.
This is always unclear to me. If there's work being done to streamline the API, why not just provide a single API that always does priority inheritance?
It seems like a recipe for disaster, but also maybe it's the only realistic way you can go to maintain backwards compatibility.
https://man7.org/linux/man-pages/man2/futex.2.html
Another special feature of futexes is that no one ever used them directly (not least because they are subtle to use correctly). Instead a few libraries used them and implemented standard APIs on top (pthread etc). Libraries like glibc and other libcs, and probably a few languages that have an aversion to using glibc. So the specific use cases of the old API are well known and scoped.
You don't need an aversion to the whole glibc to consider that "Just eat some archaic data structure" is too expensive for a language that cares about performance.
Rust's Mutex is defined over futex on Linux and some other Unix systems, srw locks on Windows because if you write it in terms of the pthread structure or the equivalent for Windows it's slower and much bigger.
Some relevant reading: https://matklad.github.io/2020/01/04/mutexes-are-faster-than...
A better question to ask might have been for examples of cases improved by the new api. (Or rather by the new features that can be added thanks to the new api). An example improvement is that by having smaller futexes (8-bit instead of 32-bit) you can fit more in a cache line which could matter for some applications, I guess.