mzimbres

10 tháng trướcdiscuss

[flagged]

2 năm trướcdiscuss

> In my experience simple blocking code is incredibly misunderstood.

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.

mzimbres

2 năm trướcdiscuss

> 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, ...)

This is a poor design because a socket read can pull multiple messages from the kernel buffers into user space and there should be a way to consumed them without Await. Many libraries however don't for watch this problem and that results in the everything is async madness.

mzimbres

2 năm trướcdiscuss

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.

mzimbres

2 năm trướcdiscuss

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.

mzimbres

2 năm trướcdiscuss

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.

mzimbres

3 năm trướcdiscuss

Implementing full-duplex protocols asynchronously is much simpler.

mzimbres

3 năm trướcdiscuss

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?

mzimbres

3 năm trướcdiscuss

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/

[2] https://github.com/boostorg/redis/issues/53

[3] https://github.com/twitter/twemproxy

mzimbres

3 năm trướcdiscuss

> 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-...

Submissions

The costs of asynchronous abstractions (C++)

comments