4 ms·
We use a very different model actually. Since spawning OS threads is expensive, we opted for the popular nonblocking-IO approach. Each worker thread (usually 1
by dcsommer 12y ago
We use a very different model actually. Since spawning OS threads is expensive, we opted for the popular nonblocking-IO approach. Each worker thread (usually 1 per core on the CPU) is given connections in a round robin fashion from the listening socket. The worker thread runs an event loop processing events on the accepted socket.
- amelius 12y agoWhat kind of programming technique did you use to implement the handling of the protocols? Did you implement them as finite-state machines, or did you use coroutines, or some other technique? Do you think that C++ is a well suited language for this kind of processing? Is it possible to say, now this project is in a mature state, that other languages (e.g. Rust) could have helped make your implementation simpler?
- seasonedschemer 12y agoHey, I'm a Software Engineer on Proxygen as well. Proxygen heavily relies on folly's buffer management abstractions such as IOBuf (https://github.com/facebook/folly/blob/master/folly/io/IOBuf.h https://github.com/facebook/folly/blob/master/folly/io/IOBuf...) and Cursor (https://github.com/facebook/folly/blob/master/folly/io/Cursor.h https://github.com/facebook/folly/blob/master/folly/io/Curso...). Protocol parsing implementation uses folly::io::Cursor to safely read byte sequences across non-contiguous buffers. Errors during parsing are wrapped up in Result types (https://github.com/facebook/proxygen/blob/master/proxygen/lib/utils/Result.h https://github.com/facebook/proxygen/blob/master/proxygen/li...) which take an inspiration from Rust. Such constructs simplify our implementation to a reasonable extent and are still low-level enough to extract performance.
- cbsmith 12y agoNote: as google discovered a few years ago, round-robining the connections is probably less than ideal.