6c6a47bf22
- we now have two interfaces for the TCP/IP server/listener workflow, based on different user approaches surrounding how to deal with the flow of accept a new tcp connection: 1. the "original" API closely mimics the low-level libuv API, in that we have an on_connect_cb that the user provides *that is ran on the libuv thread*. In this callback, the user can accept() a connection, turning it into a tcp_socket.. of course, before accepting, they have the option of passing it to a new task, provided they *make the cb block until the accept is done* .. this is because, in libuv, you have to do the uv_accept call in the span of that on_connect_cb callback that gets fired when a new connection comes in. thems the breaks.. I wanted to just get rid of this API, because the general proposition of users always running code on the libuv thread sounds like an invitation for many future headaches. the API restriction to have to choose to immediately accept a connection (and allow the user to block libuv as needed) isn't too bad for power users who could conceive of circumstances where they would drop an incoming TCP connection and know what they're doing, in general. but as a general API, I thought this was a bit cumbersome, so I ended up devising.. 2. an API that is initiated with a call to `net::tcp::new_listener()` .. has a similar signature to `net::tcp::listen()`, except that is just returns an object that sort of behaves like a `comm::port`. Users can block on the `tcp_conn_port` to receive new connections, either in the current task or in a new task, depending on which API route they take (`net::tcp::conn_recv` or `net::tcp::conn_recv_spawn` respectively).. there is also a `net::tcp::conn_peek` function that will do a peek on the underlying port to see if there are pending connections. The main difference, with this API, is that the low-level libuv glue is going to *accept every connection attempt*, along with the overhead that that brings. But, this is a much more hassle-free API for 95% of use cases and will probably be the one that most users will want to reach for. |
||
|---|---|---|
| .. | ||
| cargo | ||
| compiletest | ||
| etc | ||
| fuzzer | ||
| libcore | ||
| librustsyntax | ||
| libstd | ||
| libuv@1170ffba3a | ||
| llvm@3a57b672f8 | ||
| rt | ||
| rustc | ||
| rustdoc | ||
| rustllvm | ||
| test | ||
| README.txt | ||
| snapshots.txt | ||
This is preliminary version of the Rust compiler, libraries and tools Source layout: rustc/ The self-hosted compiler libcore/ The core library (imported and linked by default) libstd/ The standard library (slightly more peripheral code) librustsyntax/ The Rust parser and pretty-printer rt/ The runtime system rt/rust_*.cpp - The majority of the runtime services rt/isaac - The PRNG used for pseudo-random choices in the runtime rt/bigint - The bigint library used for the 'big' type rt/uthash - Small hashtable-and-list library for C, used in runtime rt/sync - Concurrency utils rt/util - Small utility classes for the runtime. rt/vg - Valgrind headers rt/msvc - MSVC support test/ Testsuite test/compile-fail - Tests that should fail to compile test/run-fail - Tests that should compile, run and fail test/run-pass - Tests that should compile, run and succeed test/bench - Benchmarks and miscellanea test/pretty - Pretty-printer tests test/auxiliary - Dependencies of tests compiletest/ The test runner cargo/ The package manager rustdoc/ The Rust API documentation tool llvm/ The LLVM submodule libuv/ The libuv submodule rustllvm/ LLVM support code fuzzer/ A collection of fuzz testers etc/ Scripts, editor support, misc