I updated the post based on the conversation below, I wholly missed an important callout about performance, and wasn't super clear that you do need to wait for the completion record to be written before responding to the client. That was implicitly mentioned by writing the completion record coming before responding, but I made it clearer to avoid confusion.
Also the dual WAL approach is worse for latency, unless you can amortize the double write over multiple async writes, so the cost paid amortizes across the batch, but when batch size is closer to 1, the cost is higher.
> This is tracked through io_uring's completion queue - we only send a success response after receiving confirmation that the completion record has been persisted to stable storage.
Which completion queue event(s) are you examining here? I ask because the way this is worded makes it sound like you're waiting solely for the completion queue event for the _write_ to the "completion wal".
Doing that (waiting only on the "completion wal" write CQE)
1. doesn't ensure that the "intent wal" has been written (because it's a different io_uring and a different submission queue event used to do the "intent wal" write from the "completion wal" write), and
2. doesn't indicate the "intent wal" data or the "completion wal" data has made it to durable storage (one needs fsync for that, the completion queue events for writes don't make that promise. The CQE for an fsync opcode would indicate that data has made it to durable storage if the fsync has the right ordering wrt the writes and refers to the appropriate fd and data ranges. Alternatively, there are some flags that have the effect of implying an fsync following a write that could be used, but those aren't mentioned)
Post talks about how to use io_uring, in the context of building a "database" (a demonstration key-value cache with a write-ahead log), to maintain durability.
Actually, this is exactly why Canada should be looking for other markets. The US has clearly indicated to us that we can no longer rely on them for trade. It's long overdue, but now is the time we need to act in reducing our dependence on the US, since clearly one dumbass can impact our economy in ways that one dumbass shouldn't be able to.
> Secret courts are a shame. Secret directives, on the other hand, can be compatible with the rule of law and an independent judiciary, provided they're lawfully authorized and can be challenged in a court.
I presume you also forgot to add this before challenged in a court...
> ..., whistleblowers are protected, and can be ...
You see, because that's the thing with secret directives, they're redacted from the public eye. The only way we get visibility into them isn't with FOIA requests, it's with whistleblowers who feel the government is doing things wrong, and if they're not protected, they rarely come forward.
> As a Canadian citizen, I urge Canada to snub Huawei too.
I'm not a fan of Huawei, but I am a fan of retaining our sovereignty. If the US wants the privilege of suggesting how we should run our country, then perhaps they should work on their end to repair the bilateral relationship. Currently, my vote is to tell them "Mind your own damned business."
Don't reject good advice just because whoever gave the advice doesn't have your best interest in mind. I've good some good advice from some otherwise awful people. Sometimes following the advice furthered their ends more than mind, but it was still the best course of action for me.
Sure, doesn't hurt to listen, but at the end of the day, that's just being polite. A courtesy. The decision is still entirely Canada's, and shouldn't be influenced by US congress critters.
The advice, and any specific allegations, should have been given much more discretely. Even in the best of times, Canadians don't like American politicians infringing on our sovereignty.
American politicians calling the Chinese security threats just means they are in the same club as ourselves as well as our Mexican and European friends. Senators Rubio and Warner will accomplish little by insulting our guests.
Huawei's bid deserves to be considered and evaluated... By Canadians, on our terms, rather than foreigners with their own agenda.
There are many people in the world who lack tact, but yet have good ideas at times. It would be to your benefit to learn to get useful things from such people. (I believe that group includes everybody at some point in their lives)
who's goals are more aligned with yours? neighbors to the south who you share a lot in common with or a totalitarian government on the other side of the planet.
> If the US wants the privilege of suggesting how we should run our country, then perhaps they should work on their end to repair the bilateral relationship
This article is based on the comments of two Senators, one a Republican who ran against Trump and the other a Democrat, asking Canada to do something. Given how close the American and Canadian economies are, it is of American concern that information which crosses north of the border might become vulnerable to Chinese exfiltration.
Sure, just saying, Canada should review any orders it makes towards telecom companies (full disclosure, I started and ran a telecom company from 2001 until 2010) from entirely a Canadian perspective and not account for any input from the US; doubly so given how the US government (like it or not, Trump is their president and reflects their government internationally) has treated Canada over the last year and a half.
Uh, not my intent. I'm trying to illustrate that Canada has command and control regulations regarding telecommunication providers that operate in the country, and there are requirements for Canadian control. If equipment were factored into such decisions, that could go a way into resolving this problem. Though it'd probably create others. And for completeness, it's still Canada's decision to make, the rhetoric the US has been sending our way has left many of us feeling like the once good friend and neighbour, has decided that we're a threat to their national security.
It's almost always more efficient to use an existing CPU if it fits your use case than to design your own. Even if it doesn't, it is often more efficient (time wise) to adapt your use case to the hardware you have available, or write software to resolve the feature you want in hardware but don't have. Only the especially nutty build their own CPUs (I'm especially nutty too)
More likely referring to the fact that Dropbox has had many an issue lately of doing things that may not have been intended to look nefarious, but look that way nonetheless. This is just the last straw for some users, whether or not the feature was used by them.
A more practical approach might be a way to stop water from going into the bowl. E.g., you lift up on the handle to close the tank flap. Or maybe there's a stop button next to the flush button.
That would be almost as good as an overflow drain, but wouldn't require adding second sewer pipe.
The overflow is only for water, right? Then a filter at the overflow entrance (or just the opening being narrow enough, two/three small holes maybe) could make positively sure the overflow bend cannot possibly get clogged.
Go is one of those languages I'd like to use more, but can't find a good fit for the kind of work I do (I mostly write iOS apps, and programming languages myself (weird dichotomy I know)).
I updated the post based on the conversation below, I wholly missed an important callout about performance, and wasn't super clear that you do need to wait for the completion record to be written before responding to the client. That was implicitly mentioned by writing the completion record coming before responding, but I made it clearer to avoid confusion.
Also the dual WAL approach is worse for latency, unless you can amortize the double write over multiple async writes, so the cost paid amortizes across the batch, but when batch size is closer to 1, the cost is higher.