.. 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!
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!)
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.
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
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
* 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..
