After most compilers started properly supporting the newer C++ standards, it seems there has been an increase in the amount of love that C++ libraries are getting. A lot of people like the to say that [x] is superior to C or C++ - often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down.
Wangle – an asynchronous C++ networking and RPC library
41–50 of 78 posts
Re: Wangle – an asynchronous C++ networking and RPC library
#42So Wangle is (mostly) a protocol agnostic platform for building asynchronous network clients and services in C++.
What transport layers are supported and can it be extended?
What I can gather, it only supports IPv4/IPv6 TCP or UDP transports. TLS is also supported.
Notably, local pipes seem to be unsupported. Those can be sometimes useful for performance and security/isolation reasons.
Re: Wangle – an asynchronous C++ networking and RPC library
#43The first thing that comes to mind after reading this is GRPC (https://github.com/grpc/grpc). That library has the advantage of supporting just about every language, not just C++.
Re: Wangle – an asynchronous C++ networking and RPC library
#44would this be useful for game development?
I can't speak for Wangle, but I've used Google's version (GRPC) to implement the networking transport for an N64 netplay hack[1] I wrote, and it was awesome.
Re: Wangle – an asynchronous C++ networking and RPC library
#45Good that they mentioned Netty as inspiration
Re: Wangle – an asynchronous C++ networking and RPC library
#46Re: Wangle – an asynchronous C++ networking and RPC library
#47Earlier quoted context omitted.
Go uses synchronous I/O backed with an M:N implementation. Rust and D use synchronous I/O backed with a 1:1 implementation. Semantically, there is no difference between the two. The difference is in the implementation, and 1:1 threading is not as slow as you think on Linux.
Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)? Conventional C++ wisdom advices against it. But then it may be informed by some old and bad pthreads implementations.
> Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)?
Yes. In fact, under Linux oftentimes spawning a thread and then running a system call can be faster than just running a system call.
> Conventional C++ wisdom advices against it.
With 32 bit CPU's you might run out of virtual memory quickly, since each thread allocates virtual memory for its stack.
With 64 bit CPU's there are no issues. (Also never forget that virtual memory isn't real memory, it's just a page counter.)
Re: Wangle – an asynchronous C++ networking and RPC library
#48[deleted]
Re: Wangle – an asynchronous C++ networking and RPC library
#49After most compilers started properly supporting the newer C++ standards, it seems there has been an increase in the amount of love that C++ libraries are getting. A lot of people like the to say that [x] is superior to C or C++ - often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down.
> often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down
I don't see how that's an argument against a language being "superior to C or C++". You can't create a self-hosting compiler for your language without having already created a non-self-hosting compiler for your language. That means every language is going to have to be "bootstrapped" in terms of something else first. C is the usual candidate just because there are a plethora of useful compiler/runtime/vm-ish libraries people like to rely on for "language prototyping" that expose C bindings—and there are very few other languages than C/C++ that have zero-overhead, zero-friction C binding support.
Rust is one of those languages—and it does indeed look like things are going in the direction of new languages getting prototyped/bootstrapped with a Rust compiler/runtime/vm instead.
Re: Wangle – an asynchronous C++ networking and RPC library
#50Earlier quoted context omitted.
I'll take a shot in the dark and say they probably value their compile times. Every boost library I've ever used has the tendency to pull in the world from a single header and take forever to compile.
ASIO can be used standalone with any C++11 compiler and the compile times are quite good. If I should make a guess then I'd say that the original author of that part of the library either started before ASIO was standalone and/or simply has a hatred for boost (which would be unwarranted), or he/she was simply more experienced with libevent... IMHO it's quite sad that they didn't use ASIO though as it's far more exten…
And interestingly, Chris Kohlhoff (asio author) is currently working on an executors library / c++ standard proposal.
Other question: how would wangle compare to Cap'n Proto (as the post mentions that wangle is an RPC framework, and is zero-copy)