2012-07-04 16:53:12 -05:00
|
|
|
/*!
|
|
|
|
* Rust bindings to libuv
|
|
|
|
*
|
|
|
|
* This is the base-module for various levels of bindings to
|
|
|
|
* the libuv library.
|
|
|
|
*
|
|
|
|
* These modules are seeing heavy work, currently, and the final
|
|
|
|
* API layout should not be inferred from its current form.
|
|
|
|
*
|
|
|
|
* This base module currently contains a historical, rust-based
|
|
|
|
* implementation of a few libuv operations that hews closely to
|
|
|
|
* the patterns of the libuv C-API. It was used, mostly, to explore
|
|
|
|
* some implementation details and will most likely be deprecated
|
|
|
|
* in the near future.
|
|
|
|
*
|
|
|
|
* The `ll` module contains low-level mappings for working directly
|
|
|
|
* with the libuv C-API.
|
|
|
|
*
|
|
|
|
* The `hl` module contains a set of tools library developers can
|
|
|
|
* use for interacting with an active libuv loop. This modules's
|
|
|
|
* API is meant to be used to write high-level,
|
|
|
|
* rust-idiomatic abstractions for utilizes libuv's asynchronous IO
|
|
|
|
* facilities.
|
|
|
|
*/
|
2012-03-28 10:51:44 -05:00
|
|
|
|
2012-04-02 11:12:43 -05:00
|
|
|
import ll = uv_ll;
|
|
|
|
export ll;
|
adding uv::direct and beginning to work out tcp request case
lots of changes, here.. should've commited sooner.
- added uv::direct module that contains rust fns that map, neatly, to
the libuv c library as much as possible. they operate on ptrs to libuv
structs mapped in rust, as much as possible (there are some notable
exceptions). these uv::direct fns should only take inputs from rust and,
as neccesary, translate them into C-friendly types and then pass to the
C functions. We want to them to return ints, as the libuv functions do,
so we can start tracking status.
- the notable exceptions for structs above is due to ref gh-1402, which
prevents us from passing structs, by value, across the Rust<->C barrier
(they turn to garbage, pretty much). So in the cases where we get back
by-val structs from C (uv_buf_init(), uv_ip4_addr(), uv_err_t in callbacks)
, we're going to use *ctypes::void (or just errnum ints for uv_err_t) until
gh-1402 is resolved.
- using crust functions, in these uv::direct fns, for callbacks from libuv,
will eschew uv_err_t, if possible, in favor a struct int.. if at all
possible (probably isn't.. hm.. i know libuv wants to eventually move to
replace uv_err_t with an int, as well.. so hm).
- started flushing out a big, gnarly test case to exercise the tcp request
side of the uv::direct functions. I'm at the point where, after the
connection is established, we write to the stream... when the writing is
done, we will read from it, then tear the whole thing down.
overall, it turns out that doing "close to the metal" interaction with
c libraries is painful (and more chatty) when orchestrated from rust. My
understanding is that not much, at all, is written in this fashion in the
existant core/std codebase.. malloc'ing in C has been preferred, from what
I've gathered. So we're treading new ground, here!
2012-03-15 23:42:07 -05:00
|
|
|
|
2012-05-25 01:42:12 -05:00
|
|
|
import iotask = uv_iotask;
|
|
|
|
export iotask;
|
2012-04-02 13:03:45 -05:00
|
|
|
|
2012-04-17 14:05:04 -05:00
|
|
|
import global_loop = uv_global_loop;
|
|
|
|
export global_loop;
|