> You do not really await anything. What actually happens is an event handler gets called on an event,
So the event handler gets called immediately? No that’s not right. What would be the point of that? The event handler or continuation obviously needs to be scheduled on something that is awaitable. Meanwhile, other concurrent tasks may be able to run.
> This is the essence of asynchronous programming. There are no tasks, no yielding, practically no overhead and everything is deterministic
There is nothing inherent about async and await that prevents “yielding”... the issue of yielding and semaphores is a concurrency issue and since async and await are used in concurrent programming environments, the same issues apply.
While it is true async and await don’t require any kind of cooperative concurrent framework to work, that is kind of their whole point for existing. A single task async/await system isn’t terribly interesting.
Like all “good” tech ideas this isn’t a terribly bad idea on its surface. It has no tech requirements. Running this just sounds like a nightmare. I really don’t want to be adminning griefing and trolling targeted at cancer patients.
Well run moderated communities for the dying are nothing new.
This is no different than async/await. At some point you await a scheduled primitive, it could be a timer, io readiness, an io completion... and yield to a scheduler. You don’t specify explicitly when you return. These are not tightly coupled coroutines. This is precisely what is going on in cooperative multitasking.
I don’t see how this increases overhead to deal with either.
Basically, coop multitasking and async/await operate on the exact same execution framework, the latter just gives convenient syntactic support.
Perhaps you should see how typescript turns async await into js.
> in one control is just given up and regained unpredictably
Which one? It’s “cooperative” ie not unpredictable. The points where one can block are predictable and documented explicitly, otherwise how would the programmer know they won’t block forever. The same should hopefully be the case for async/awaitable apis.
In fact where async/await will actually give up control are harder to tease out.
The differences are really not as big as they would seem.
He’s not getting swap. Or in a sense he is... you can still thrash.. the read only pages of the executable and any memory mapped files are still eligible to be paged out. When you get into a memory pressure situation you end up with a handful of executable pages of all the active programs getting faulted-in on every context switch.
Worse is better is a simple minded and wrong interpretation. In reality the outward simplicity of pledge(2) masks a great deal of high quality engineering and research. The categories for pledge were not just pulled out of someone’s ass.
Seccomp like so many Linux interfaces is the “fuck it” here’s an exhaustive yet half baked set of tools, you can do anything! This barely works out in gp programming, but is always an unmitigated disaster in anything security related.
Perhaps a better term would be “pool”. Anyway, what’s being leaked is “handles” or events not actually fds. You only actually need as many fds as the maximum possible number passed to a syscall. The mapping of handles/event objects in user space does not have to be 1:1 with the kernel resource.
If you read the full thread that is a bit of a red herring and beside the point (thats why I said the conveyance of the performance implication was poor)... indeed window WFMO only supports 64 objects per call. They mention that the fd issue is due to leaking objects in many windows programs..which was an odd mention and a little off the main subject. The main motivator is performance. If eventfds performed better it would likely be better to fix the fd leak issue with a cache.
Again.. eventfd and epoll covers the same use case as WFMO and EVENTs.
Linux already has what you’re talking about with eventfd and epoll.
In Linux each thread can get an eventfd and you can POLLIN all of them.
In fact I would argue that using futexes is the “roll your own solution” using lower level primitives (and easier to fuckup) much more so than eventfd and epoll.
As mentioned somewhat poorly in the post, using futexes gives a performance boost which is not surprising since they are fast user mutexes. FWIW I didnt think windows events had a fast user space path but I may be mistaken.
For most worker pool scenarios you’re describing, the overhead of eventfd is probably in the noise.
The short answer is it can be both (ie safe, beneficial and effectively a patent grab). It is also unlikely that an enantiopure chemical is less safe then it’s racemic counterpart and not unlikely that it is beneficial (this is not without precedent... this is also chemistry 101 and I don’t feel this is the forum for it)...
The doubt is not so much the safety but is the benefit of the enantiopure version worth the cost.
> I don't have numbers to counter this off the top of my head, but congenital adrenal hyperplasia is a rare syndrome, but still common enough that it is taught to every medical student and tested on our boards repeatedly.
You are confusing Congenital adrenal hyperplasia (ie 21 alpha hydroxylase deficiency), the bane of every 3rd year med student and adrenal medullary hyperplasia, a much rarer condition (I don’t recall it ever coming up during medical school).
Congenital Adrenal hyperplasia involves the cortex where the corticosteroids are produced. Epinephrine and norepinephrine are catecholamines produced by the medulla. AMH is more similar to pheochromocytoma though.
Temperature sensors in thermostats are nowhere near as precise as you seem to believe. And unless you have calibrated your sous vide to a standard I am willing to bet good money its not anywhere within 1 degree precision (having tested this.. you’re lucky to get +/- 3 C). Also nothing in cooking requires the precision down to fractional degrees C. You’re not going to obtain it anyway, even if you think you are.
If it’s a recurring payment for a contract term sure. But most free trial offers are “cancel anytime” and pay in advance of the next subscription period. There’s nothing for them to pursue you for if you decline to pay. They just stop providing the service.
What you’re saying makes little sense for most “free trial” offers. These offers do not come with a term agreement (ie they are cancel anytime), and furthermore they are prepay. Ie you are offered a trial period and then you are billed in advance for the continuing service. So without a term agreement and prepay you’re not on the hook for anything. You just never paid, they terminate your service and that’s it.
Sickle cell, lupus, hypertension, IQ, diabetes, etc etc are all not distributed evenly across race or sex. Also, environmental factors and epigenetics interact in complex ways. I would not be at all surprised that there’s a prevalence difference among racial or social groups.
Safari still has an open issue I think. But that’s no surprise since Apple has demonstrated they’re suckitude at software security and development in general.
The Walkman was sold until recently (if it isn’t still) and of course living in a big city you see a handful of people using a Walkman. It never died completely. There is of course the hipster resurgence of cassettes of the 2010s. Of all this I’m aware. But techie or hipster or not I was around in 2001 and the Walkman was well past mass adoption by that point in the western world. Shitty MP3 players that people loaded up with Napster and Discmans/Aiwas knockoff were what the poors and regulars did. MD and nicer hard drive players were the enthusiast options.
The iPod did not have the Walkman to contend with in a meaningful sense.
Also in the US at least, the majority of households had a PC by 2001. I came from a shit poor backwater by this sites standards. We had computers.
And by 2001, FTP sites? That was post peak of Napster (after Feb 2001). Kazaa, Emule, etc were all regulars options. You’re a few years off, which was substantial in the 95-2001 timeframe.
So the event handler gets called immediately? No that’s not right. What would be the point of that? The event handler or continuation obviously needs to be scheduled on something that is awaitable. Meanwhile, other concurrent tasks may be able to run.
> This is the essence of asynchronous programming. There are no tasks, no yielding, practically no overhead and everything is deterministic
This is just totally wrong. Especially re tasks: https://docs.python.org/3/library/asyncio-task.html#creating...
There is nothing inherent about async and await that prevents “yielding”... the issue of yielding and semaphores is a concurrency issue and since async and await are used in concurrent programming environments, the same issues apply.
While it is true async and await don’t require any kind of cooperative concurrent framework to work, that is kind of their whole point for existing. A single task async/await system isn’t terribly interesting.