mzimbres
Joined 6 years ago
Karma
35
Submissions
19
Member since
Apr 11
Recent submissions
Comment · 1 year ago
Comment · 2 years ago
> In actual real applications it is not always possible
This depends on what are your expectation. IO operations must suspend to wait for data read and writes, therefore it is not possible to avoid Async/Await. In other cases you might have multiple tasks depending on a specific IO operation, for example, one connection to a database that is used by multiple HTTP sessions, here it is also not possible to avoid Async/Await because those sessions are bound to an IO operation.
The real problem however comes when tasks that can complete synchrously are implemented with an asynchronous interface, for example
message = Await websocket.read(socket, buffer, ...)
Comment · 2 years ago
Only in poorly designed code you have problems like this where Async Await goes viral. It can be avoided by spiting libraries into an IO part that uses Async/Await and a protocol part that is sans-io. Using async code to access data that is already in the application memory is inefficient and should be implemented synchronously with regular functions instead of asynchronously.
Comment · 2 years ago
Here is a low hanging fruit for governments around the world fighting low birth rates. Allow your people to work from home and they will start having more babies, simplle as that. I am my wife had to switch jobs just so we could work more from home, an unnecessary annoyance.
Comment · 2 years ago
I wonder how did they shared the meat with the rest of the group after chasing down the prey for an hour in random directions.
Comment · 3 years ago
Implementing full-duplex protocols asynchronously is much simpler.
Comment · 3 years ago
So why rotten meat smells terrible and a steak delicious? Why would we evolve that perception of something that nutritious and which could prevent me from starving. Why my nose keeps telling me to keep away from rotten meant?
Comment · 3 years ago
I haven't created Redis itself but a Redis client library. It all started with a chat server I wanted to write on top of Boost.Beast (and by consequence Boost.Asio) and at the time none of the clients available would fill my needs and wishes
- Be asynchronous and based on Boost.Asio.
- Perform automatic command pipelining [1]. All C++ libraries I looked at the time would open new connections for that, which results in unacceptable performance losses.
- Parse Redis responses directly in their final data structures avoiding extra copies. This is useful for example to store json strings in Redis and read them back efficiently.
With time I built more performance features
- Full duplex communication.
- Support for RESP3 and server pushes on the same connection that is being used for request/response.
- Event demultiplexing: It can server thousands of requests (e.g. websocket sessions) on a single connection to Redis with back pressure. This is important to keep the number of connections to Redis low and avoid latency introduced by countermeasures like [3].
This client was proposed and accepted in Boost (but not yet integrated), interested readers can find links to the review here [2].
[1] https://redis.io/docs/manual/pipelining/
Comment · 3 years ago
> But as more and more engineers joined us, some shortcomings
> of C++ came to bite us: unreadable coding style, memory leak,
> segmentation fault, and more.
* unreadable coding style: This is not a C++ problem. * memory leak: Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers.
The only point that could be attributed to C++ is the segfaults perhaps, due to its lack of safety. But your other two points made me skeptical about Rust bringing you much benefit. I am specially concerned about throwing away months worth of code. Rewriting everything from scratch is what newbies love to do and will most likely get you in the same mess you were in. Try to learn with the error of others [1]. And btw, the problem is usually who writes the code and not which language is used.
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Comment · 4 years ago
Senders and Receivers is the next big thing Eric is delivering to C++, stay tuned.
I don't think so. You can't even implement a full-duplex protocol properly with sync IO since reading and writing can't happen at the same time on the same thread. Splitting them to different threads also won't help since accessing shared state requires synchronization with e.g. mutex that kills again simultaneous reading and writing.