- 23 5月, 2012 40 次提交
-
-
由 Brian Anderson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
- change port of tcp server test in uv_ll to avoid conflict w/ test in net::tcp - a few places the tcp::read fn is used in test w/ a timeout.. suspend use of the timeout from here on out.
-
由 Jeff Olson 提交于
also: read_future ala write_future .. woooooohooooooooo
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
* there are a few places where I was experimenting w/ using `alt` in places where `if`/`else` would've sufficed. don't drink the koolaid! * I had an unneeded `else` structure (the `if` branch that preceeded concluded with a `fail` statement.. I added the `fail` later in the dev cycle for this branch, so I forgot to remove the `else` after doing so) * consistent wrt `prop_name: value` vs. `prop_name : value` in record decl and initialization * change an `alt` exp on an `ip_addr` to actually be exhaustive, instead of using a catch-all clause
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
.. this test fails frequently, locally, when ran with the batch of other global_loop tests running due to how valgrind deals with multithreading in the test app. not sure what to do, here.
-
由 Jeff Olson 提交于
- 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.
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
.. turns out that, without the export, the modules aren't accessible outside of the crate, itself. I thought that, by importing some module into another (nesting it) and exporting from that nested module (which is, itself, exported from std.rc) that my mod would be in the build artifact. This doesn't appear to be the case. learning is fun!
-
由 Jeff Olson 提交于
I need these in the context of doing various malloc/free operations for libuv structs that need to live in the heap, because of API workflow (there's no stack to put them in). This has cropped up several times when impl'ing the high-level API for things like timers, but I've decided to take the plunge and use this approach for the net::tcp module. Technically, this can be avoided by spawning a new task that contains the needed memory structures on its stack and then having it block for the duration of the time we need that memory to be valid (this is what I did in std::timer). Exposing this API provides a much lower overhead way to address the issue, albeit with safety concerns. The main mitigation policy should be to use malloc/free with libuv handles only when the handles, are then associated with a resource or class-with-dtor. So we have a finite lifetime for the object and can gaurantee a free(), barring a runtime crash (in which case you have bigger problems!)
-
由 Jeff Olson 提交于
.. going to rework the listen() API to be non-blocking.
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
also whitespace cleanup .. for now, the test just spins up the server and listens for messages, echoing them back to an output port. there's a "kill" msg that it will listen for. need to point the tcp client and server test impls at each other for a loopback server/client test, like how its done in uv::ll once ipv6 parse/format lands, i can add another test using the entirely same codebase, but substituting an ip_addr ipv6 varient for the ipv4 varient used in the existing code still need some other plumbing to get the client/server tests to work together.
-
由 Jeff Olson 提交于
still need implementation for parsing/output formatting and (perhaps?) representation (for now, i just followef the ipv4 variant's lead and am representing it as a tuple of 8x u16). parsing an ipv6 addr is way more complex than parsing an ipv4 addr, so i'm putting off an implementation here, for now. candidate solutions: - could use getaddrinfo() (exists on both POSIX and windows), but with incompatible fn signatures. - libuv has a way to parse an ipv6 string into a sockaddr_in6, but it also requires a port, so it's probably not aprop for ip_addr
-
由 Jeff Olson 提交于
more flexibility..
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
they're changed into a net::tcp::tcp_err_data record, for now. once the scope of possible tcp errors, from libuv, is established ill create an err type for each one and return those where they might occur
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
* tweaked the layout of sockaddr_in6 struct in anticipation of future use * changed several uv:ll fn signatures to use generics and be more flexible with ptr types they get passed * add uv_err_data and a help fn to return it.. packages up err_name and err_msg info from uv_get_last_error() stuff..
-
由 Jeff Olson 提交于
-
由 Jeff Olson 提交于
-
由 Brian Anderson 提交于
Added support for #! comments. Closes issue 1772.
-
由 Tim Chevalier 提交于
And monomorphize dtors correctly.
-
-
由 Brian Anderson 提交于
-
由 Margaret Meyerhofer 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
Nothing on Earth depends on this functionality and it is probably unexpected
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-