[HN Gopher] A Universal I/O Abstraction for C++ (2020)
___________________________________________________________________
A Universal I/O Abstraction for C++ (2020)
Author : vg_head
Score : 67 points
Date : 2021-04-17 09:34 UTC (1 days ago)
(HTM) web link (cor3ntin.github.io)
(TXT) w3m dump (cor3ntin.github.io)
| jcelerier wrote:
| In the end the overall design looks like a semi-reified
| asynchronous dataflow programming API based on coroutines.
|
| I think that it would be useful to consider the existing (very
| very very large) body of research on dataflow PL and APIs; e.g.
| check this paper from 1982 which talks about dataflow,
| coroutines, for handling file operations:
|
| - https://scholarship.claremont.edu/cgi/viewcontent.cgi?articl...
|
| More recent papers in the field:
|
| - https://hal.archives-ouvertes.fr/hal-02865894/document
|
| - https://library.oapen.org/bitstream/handle/20.500.12657/3772...
|
| and older general overviews of the field:
|
| - http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Liter...
|
| - http://210.47.10.86:8032/200009-3/65492.pdf#page=141
|
| My main concern with this design, even if the code looks quite
| neat, is that the actual dataflow graph is not reified, but
| exists "invisibly" as part of the program source through the way
| co_await calls are sequenced.
|
| This means that it is not possible to do as an user, a static
| analysis and scheduling of the tasks : it relies on the compiler
| to perform this. But, this problem is in my experience quite
| often very use-case-specific and ridden with informations
| compilers do not possess. Not having the way tasks are
| interdependent reified in an actual user-manipulable "graph"
| object means that users won't have the possibility, to, say,
| perform a topological sort or flow propagation on their async
| graph in order to extract information on it that could be
| necessary to perform a domain-specific optimization of said graph
| (for instance if we know that a set of tasks are dependent on
| each other in ways that aren't visible on the source code, but
| are known to the programmers, it would make sense to schedule
| them on a queue in their own thread).
| gpderetta wrote:
| Hum, in principle you can do arbitrary compile time
| transformations to the datagraph before submitting it via
| metaprogramming.
|
| If you really want you could even convert the graph (fully or
| partially) to a runtime representation.
|
| The core of the proposals are not about specific classes or
| functions other than some default algorithm implementations.
|
| Instead they are mostly about defining concepts and protocols
| so that independent async domains can coexist and iteroperate
| in the same application.
|
| This is similar to the STL where the most important part are
| the various iterator concepts and the algorithm interfaces, not
| the actual algo implementations and the containers.
| motakraxxer wrote:
| Could you please show an example for it?
| jcelerier wrote:
| In c++ some examples would be RaftLib or cpp-taskflow
| bregma wrote:
| I would hesitate to embrace a "universal" I/O abstraction that is
| architected around a monolithic kernel. Linux and Windows are not
| the only game in town. This design make make for a nice third-
| party library for some applications, but it has no place being
| cemented into the standard library.
| jbluepolarbear wrote:
| There's only one C++ library I'll use for I/O and networking and
| that's POCO C++. I've used it in a lot of project over the last
| 10 years and I haven't seen a better solution.
| synergy20 wrote:
| its open source version has Boost license which is fine, not
| sure what's the difference between this and its POCO Pro
| product, it's better than QT license model for sure, but worse
| than than those "here is _all_ the code, pay me if you need
| professional service but not the code"
| secondcoming wrote:
| C++'s networking support is one of its greatest shortcomings. If
| I had the choice, I'd never use ASIO again and just use libuv.
|
| Coroutines look interesting, I just need to get my head around
| them. All code examples I've seen, just as with ASIO, deal with
| the happy path only. For example, there's hardly a mention of
| timeouts and the faff ASIO makes you do to get them to work. If
| there's no 'read(..., timeout)' function then the API is broken
| as far as I'm concerned.
|
| Then you'll (probably) need to write your own HTTP parsing code
| which, when you're half-way through, will make you realise that
| HTTP is actually not trivial at all to implement correctly. Best
| of luck writing your own HTTP2/3 engine. Boost.Beast seems like a
| great attempt at doing it right, but I've never used it. (HTTP
| needs to die, but that's a rant for another day)
|
| IMO, it's too late for C++ and networking. If you need to read
| from something simple like a serial device then fine, it's
| probably ok. If you actually need to talk across the Internet
| then there are other languages that will do it better than you
| can.
|
| Having said all this, personally, I know my limits and could
| never come up with anything better than ASIO.
| synergy20 wrote:
| what about POCO libs mentioned above for network and IO
| applications?
| jfrd wrote:
| Too bad C++ is the most terrible thing since forever.
|
| https://twitter.com/Cor3ntin/status/1383875999033565194?s=20
| emsy wrote:
| All those "orange site bad" comments lol
| pjmlp wrote:
| Nah, that place I leave for C, the number one reason we keep
| having memory corruption issues during the last 50 years of
| computer history, and having taited every language that has
| some level of compatibility with it.
| linkdd wrote:
| This kind of comments are forgetting all the good that C did
| bring in the last 50 years of computer history.
|
| <sarcasm>Too bad those shitty engineers in the 70s didn't
| think of Rust...</sarcasm>
| miohtama wrote:
| They thought many ideas of it (see Lisp, Smalltalk) but
| computers where not powerful enough for complex compilers.
| Instead, the burden of ensuring correctness had to be left
| as the cognitive burden for the developer for decades to
| come.
| jabl wrote:
| > <sarcasm>Too bad those shitty engineers in the 70s didn't
| think of Rust...</sarcasm>
|
| True, Rust didn't exist back then, and yes, some (few!)
| features in Rust weren't invented and worked out then, like
| the ownership model.
|
| OTOH the corollary to that statement isn't that C was some
| shining beacon of good design taking advantage of the then
| state of the art programming language knowledge. See e.g.
| https://pastebin.com/UAQaWuWG
| rualca wrote:
| That pastebin leaves out the fact that C's spartan
| approach and extreme simplicity allowed C to become the
| most popular programming language in the world already in
| the time of K&R, a book still renowned for it's clarity
| and low mental baggage required to onboard onto a
| programming language.
|
| The pastebin also left out that Bjarne Stroustrup
| developed C with classes, and the C, as a backward
| compatible superset of C to take advantage of C's
| unrivaled popularity.
|
| We all can agree that the science and art behind
| programming language design progressed a lot in the four
| decades where we enjoyed C. However, it feels a kin to
| rewriting history to depict C as a subpar language that
| was poorly designed and had little to no redeeming
| qualities, when facts speak for themselves.
| mhh__ wrote:
| Adding slices to C would kill a lot of bugs without going
| all the way to rust.
| xjay wrote:
| The late pioneer in compiler optimization--Frances Allen--
| agrees.
|
| 2006: "..but something else had happened--and that was back
| in 1973--[something] which I was very, very unhappy about--
| and that was the advent of C! It derailed, as far as I was
| concerned, the advances that I foresaw in compilers. One
| _cannot_ let the user play with the addresses, and use
| procedures, and play with pointers--which is pointing to the
| data--and be able to understand how one can transform the
| program to run more optimally. "
|
| "There was an interesting debate at the SIGPLAN conference in
| that period--about the relative need for optimization. It was
| put on the table that it wasn't going to be needed anymore!
| So. Anyway. You can have your own opinion on that, but I know
| I have mine, beyond a doubt that it was a huge setback for--
| in my opinion--languages and compilers--and the ability to
| deliver performance--easily--to the user."
|
| https://en.m.wikipedia.org/wiki/Frances_Allen
|
| https://www.youtube.com/watch?v=NjoU-MjCws4&t=2450
| titzer wrote:
| She's exactly right. I'm really not sure how we came to
| accept the worse-is-better argument that high performance
| required exposing machine details into the source language,
| and letting compiler writers just "do whatever is fastest",
| regardless of safety. What it gave rise was to today's
| situation where _none of_ application writers, library
| writers, kernel writers, or compiler writers are quite sure
| what will happen if a new optimization is introduced. Will
| it break programs? By how much? Well, let 's roll the dice!
| This is a direct result of allowing--no--even expecting,
| programmers to peer behind the curtains to see machine
| details that they frankly, shouldn't. It's why porting
| programs from one machine to another is even a thing, as
| opposed to just selecting a different output from a
| compiler, or running a different VM.
|
| Proper abstractions define exactly what happens in every
| situation, and design unobservable details out. It is the
| basis for optimizations that fundamentally cannot observed
| (except side-channels, like timing and other resource
| usage). Proper abstractions is why we have fast processors.
| The ISA is a hard boundary.
___________________________________________________________________
(page generated 2021-04-18 23:01 UTC)