Readit NewsBut if you're writing code at a higher level than the bsd sockets api, it's a whole can of worms.
And, the moment you start flushing correctly: if(flush(...)) { abort(); }, it becomes infallible from the program's point of view, and can be safely invoked in destructors.
File closure operations, on the other hand, do have legitimate reasons to fail. In one of my previous adventures, we were asking the operator to put the archival tape back, and then re-issuing the close() syscall, with the driver checking that the tape is inserted and passing the control to the mechanical arm for further positioning of the tape, all of that in the drivers running in the kernel space. The program actually had to retry close() syscalls, and kept asking the operator to handle the tape (there were multiple scenarios for the operator how to proceed).
Retrying close() is dangerous, if the file descriptor was successfully deallocated, it might have already been re-allocated by another thread. I'd guess the program you're describing was single threaded though (it can still bite there though)
How could one fix that though? It seems pretty unavoidable to me because write() is more or less asynchronous to actual disk I/O.
You could add finalize() which is distinct from close(), but IMHO that's even more confusing.
I, Tom Lehrer, individually and as trustee of the Tom Lehrer Trust 2007, hereby grant the following permissions: All copyrights to lyrics or music written or composed by me have been permanently and irrevocably relinquished, and therefore such songs are now in the public domain. All of my songs that have never been copyrighted, having been available for free for so long, are now also in the public domain. In other words, I have abandoned, surrendered and disclaimed all right, title and interest in and to my work and have injected any and all copyrights into the public domain.
The permission granted includes all lyrics which I have written to music by others, although the music to such parodies, if copyrighted by their composers, are of course not included without permission of their copyright owners. The translated songs on this website may be found on YouTube in their original languages. Performing and recording rights to all of my songs are included in this permission. Translation rights are also included.
In particular, permission is hereby granted to anyone to set any of these lyrics to their own music, or to set any of this music to their own lyrics, and to publish or perform their parodies or distortions of these songs without payment or fear of legal action.
Some recording, movie, and television rights to songs written by me are merely licensed non-exclusively by me to recording, movie, or TV companies. All such rights are now released herewith and therefore do not require any permission from me or from Maelstrom Music, which is merely me in another hat, nor from the recording, movie, or TV companies involved.
In short, I no longer retain any rights to any of my songs.
So help yourselves, and don’t send me any money.
NOTICE: THIS WEBSITE WILL BE SHUT DOWN AT SOME DATE IN THE NOT TOO DISTANT FUTURE, SO IF YOU WANT TO DOWNLOAD ANYTHING, DON’T WAIT TOO LONG.
Tom Lehrer November 26, 2022
You can help out by hosting a copy somewhere!
They used to be a crown-jewel of US tech. But it seems like every time I read the news, they are announcing a delay or shutting down some product.
IMHO the whole user-visible p-core/e-core thing on desktop CPUs is one of the worst decisions in the history of microprocessors. My gaming machines need to do double-duty as as build boxes, so they're just utterly unusable for me.
I completely stopped using chromium two years ago and haven't looked back.
A typical car uses ~25kg of copper - that's enough for approximately 0.5m of HVDC.
The EU currently produces 12mln cars annually, down 3mln from the 2017 peak.
In other words there should be no issue with ramping up demand for the equivalent of 1500km of HVDC annually in the EU alone - a rate much higher than the local bureaucracy could manage issuing permits for.
EDIT2: I'm doing a bad job of explaining this... you obviously need the keypair associated with the cert to initiate connections with it and not trigger MITM alerts. But if you break the hash function, you don't need the private key from the root cert, the verbatim signature from the original cert will appear to be valid when spliced into your forged cert if the hash digest computation on the forged cert is the same.
But in the end, it's a trade-off, like everything in language design. (In life, really. ;) We think that in Rust we may have found a new sweet spot for this kind of optimizations. Time will tell whether we are right.
> The rules we are proposing for Rust are very different. They are both more useful for compilers and, in my opinion, less onerous for programmers.
My question was too vague, what I meant to ask was: what aliasing optimizations will be possible in Rust that aren't possible in C?
Example 18 in the paper is one, if I'm understanding it. But that specific example with a pointer passed to a function seems analogous to what is possible with 'restrict' in C, I'm struggling to come up with more general examples that don't involve gratuitous globals.
It seems to me like having to allow for the possibility of unsafe constrains the ability to do "heroic" optimizations such as what jcranmer described elsewhere in the thread. If that is true to some extent, is there a future where Rust might optimize more aggressively if the programmer promises not to use unsafe anywhere in the program? That's something I've always been curious about.
How would this work practically? If a single client is overflowing the edge router queues you are kindof screwed already? Even if you dropped all packets from that client you would need to still process the packets to figure out what client they belong to before dropping the packets?
I guess you could somehow do some shuffle sharding where a single client belongs to a few IP prefixes and when that client misbehaves you withdraw those prefixes using BGP to essentially black hole the network routes for that client. If the shuffle sharding is done right only the problem client will have issues as other clients on the same prefixes will be sharded to other prefixes.
In modern Linux you can write BPF-XDP programs to drop traffic at the lowest level in the driver before any computation is spent on them at all. Nearly the first thing the driver does after getting new packets in the rx ring buffer is run your program on them.