Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wangle – an asynchronous C++ networking and RPC library

code.facebook.com

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Wangle – an asynchronous C++ networking and RPC library

#21

Post by thepumpkin1979 »

tptacek wrote: post #10
pcwalton wrote: post #9

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

Why are we talking about Go, Rust, and D on a thread about a new C++ library? I mean, I know the answer, but I wish we weren't. I ordinarily wouldn't care, but I usually feel like I have something to learn from ambitious networking libraries even when they're written in languages I prefer not to use.

I just wanted to point out the barriers a developer faces when trying to use C++. Sorry, I can't resist compare it to what I know, which happens to be other programming languages different to C++.

Re: Wangle – an asynchronous C++ networking and RPC library

#22

Post by x5n1 »

thrownaway2424 wrote: post #20
x5n1 wrote: post #2

In 2016 I would write networking and RPC in go.

Because you want to spend 10x as many CPUs?

Mostly because it's easier, performant, and because of the nature of the language it's less likely I would make a mistake doing anything in the language compared to C++ or C.

Re: Wangle – an asynchronous C++ networking and RPC library

#23

Post by jhartmann »

I have used this library pretty heavily in some of my recent work and I love how easy it makes building performant async network servers in C++. Minor nitpick: It would be nice though, if they built shared libraries by default though, last release I took I had to tell cmake to make a shared library. Since this is used by fbthrift as a dependency, I think it really makes sense to build it that way by default. I also use fblualib and it builds with a very old version of some of these libraries probably because the FAIR team didn't want to mess with tweaking the builds so they can work with standalone wangle (parts of the library used to be part of folly).

Re: Wangle – an asynchronous C++ networking and RPC library

#24

Post by vvanders »

je42 wrote: post #7

does anybody know why this library is not based on (boost::)asio ?

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.

Re: Wangle – an asynchronous C++ networking and RPC library

#25

Post by zzzcpan »

thepumpkin1979 wrote: post #8

I just tried to compile folly in OSX and it fails to compile with homebrew. https://github.com/facebook/folly/issues/400 Also, Once I manage to compile folly and then wangle, what kind of database drivers can I use in conjunction with this? Would I shoot myself in the foot if I use this with libpq under CPUThreadPoolExecutor? Same with Rust and dlang, I'm not sure how to apply the freedom to have pluggable executor i…

> what kind of database drivers can I use in conjunction with this?

Usually synchronous database drivers have to be reimplemented in an asynchronous fashion to work with event loops. It's not very hard though, could be as simple as adding jump tables and context structures into synchronous functions.

Emulating asynchronous execution with a thread is ok too. You do that to access filesystem anyway.

But if your first thought is about accessing a database server - you probably don't need to go asynchronous at all.

Re: Wangle – an asynchronous C++ networking and RPC library

#26

Post by 420TOKER »

educar wrote: post #3

Had to look up the meaning of wangle. "obtain (something that is desired) by persuading others to comply or by manipulating events." Does anyone know where facebook is coming up with all these words - folly/wangle?

beats me i wonder the same thing all the time

Re: Wangle – an asynchronous C++ networking and RPC library

#27

Post by lhecker »

vvanders wrote: post #24
je42 wrote: post #7

does anybody know why this library is not based on (boost::)asio ?

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

Re: Wangle – an asynchronous C++ networking and RPC library

#29

Post by malkia »

zzzcpan wrote: post #25
thepumpkin1979 wrote: post #8

I just tried to compile folly in OSX and it fails to compile with homebrew. https://github.com/facebook/folly/issues/400 Also, Once I manage to compile folly and then wangle, what kind of database drivers can I use in conjunction with this? Would I shoot myself in the foot if I use this with libpq under CPUThreadPoolExecutor? Same with Rust and dlang, I'm not sure how to apply the freedom to have pluggable executor i…

> what kind of database drivers can I use in conjunction with this? Usually synchronous database drivers have to be reimplemented in an asynchronous fashion to work with event loops. It's not very hard though, could be as simple as adding jump tables and context structures into synchronous functions. Emulating asynchronous execution with a thread is ok too. You do that to access filesystem anyway. But if your first t…

> Emulating asynchronous execution with a thread is ok too

Straying away from the topic, but I used to support a file streaming library for the game studio I worked with, and while this approach worked, some things were not gracefully handled - for example canceling reading in the middle, or somehow giving all your I/O requests to the underlying system, so it can decide what's the best way to read them (aio?).

Re: Wangle – an asynchronous C++ networking and RPC library

#30

Post by ot »

educar wrote: post #3

Had to look up the meaning of wangle. "obtain (something that is desired) by persuading others to comply or by manipulating events." Does anyone know where facebook is coming up with all these words - folly/wangle?

"folly" is a play on Facebook Open-source LibrarY. I think using uncommon English words helps with searchability, although of course is not as good as made-up words or acronyms.
Post reply on HN