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

31–40 of 78 posts

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

#31

Post by mr_sturd »

educar wrote: post #19
cgh wrote: post #13

Earlier quoted context omitted.

"Folly" is a relatively common English word. "Wangle" is less common but I still see it from time to time. What I find more interesting than the naming is FB's willingness to remove features from Folly as they are made redundant by Boost or std. I'm unaccustomed to such a lack of arrogance from a major player.

Doesn't removing features break backward compatibility? My favorite C++ library is Qt; they never remove public API for that reason. In Qt world, we update regularly to get the bug fixes and other features. Last thing I want to do is port my code to some other new API to update the library.

If it's a feature that has made it into the std/Boost libraries, we'll be talking atomic utility functions which are being removed, in favour of calling the std/Boost ones. Not actual API-level features.

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

#33

Post by jhartmann »

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…

The wangle native way of doing this is just to use an IOThreadPoolExecutor: https://github.com/facebook/wangle/blob/master/wangle/concur... Just make a block of threads to run your db tasks, and you can use a promise/future to return the results back to the async code.

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

#34

Post by dunkelheit »

pcwalton wrote: post #9
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…

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.

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

#35

Post by jhartmann »

dunkelheit wrote: post #34
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.

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.

A reasonable compromise is to use a threadpool (which is a big part of what comes with wangle) with a fixed number of threads and you queue the tasks to be run by the threads. It works quite well in practice, and you can use coroutines (I'm most familiar with the implementation in boost coroutine and the Ewan webserver personally) to go the whole hog and get something as lightweight as Erlang green threads or goroutines. I would only bother doing that of course if in your particular use case you find the threadpool doesn't perform well. With proper sizing and broken up units of work, it really works quite well in practice.

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

#36

Post by pcwalton »

dunkelheit wrote: post #34
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.

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.

Usually memory usage ends up being the limiting factor, not thread spawning performance. Memory usage is independent of 1:1 vs. M:N, though, as pthread stack sizes are configurable.

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

#38

Post by fugalh »

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?

When I name things I look for a word that doesn't get drowned out by unrelated hits in search engines, and has some kind of link to what the library does. Straightforward names are great when they are obvious, easy to remember, and not a search disaster. Otherwise clever memorable names make a pretty good substitute.

I picked the name Wangle because it is a synonym to Finagle, and because I couldn't think of a simple self-descriptive name. I think I also had the Edward Lear poem in the back of my subconscious.

We don't have a central naming authority - people just name their projects whatever they want. Sometimes we have to or want to rename things for various reasons but it's mostly similar to the open source world.

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

#39

Post by vvanders »

lhecker wrote: post #27
vvanders wrote: post #24

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

That's the thing about reputation though, really easy to burn and really hard to earn back.

I've worked on projects where touching a main header incurred a 1 hour compile even with Incredibuild. You can understand how people can get sensitive with compile times in cases like that.

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

#40

Post by fredemmott »

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…

There's https://github.com/facebook/squangle for MySQL, though it's lacking documentation, and requires a https://github.com/facebook/mysql-5.6 or WebScaleSQL client library
Post reply on HN