mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fcc973b5ac
rust/src/libstd/uv.rs

1313 lines
44 KiB
Rust
Raw Normal View History

stdlib: Stop incurring vtable dispatch costs when hashmaps are used This required changing almost all users of hashmaps to import the hashmap interface first. The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
2012-03-07 18:48:57 -06:00
import map::hashmap;
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
export loop_new, loop_delete, run, close, run_in_bg;
export async_init, async_send;
export timer_init, timer_start, timer_stop;
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
export uv_ip4_addr, uv_ip6_addr;
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// these are processed solely in the
// process_operation() crust fn below
enum uv_operation {
op_async_init([u8]),
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
op_close(uv_handle, *libc::c_void),
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
op_timer_init([u8]),
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
op_timer_start([u8], *libc::c_void, u32, u32),
op_timer_stop([u8], *libc::c_void, fn~(uv_handle)),
op_teardown(*libc::c_void)
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
enum uv_handle {
uv_async([u8], uv_loop),
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
uv_timer([u8], uv_loop),
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
enum uv_msg {
// requests from library users
msg_run(comm::chan<bool>),
msg_run_in_bg(),
msg_async_init(fn~(uv_handle), fn~(uv_handle)),
msg_async_send([u8]),
msg_close(uv_handle, fn~()),
msg_timer_init(fn~(uv_handle)),
msg_timer_start([u8], u32, u32, fn~(uv_handle)),
msg_timer_stop([u8], fn~(uv_handle)),
// dispatches from libuv
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
uv_async_init([u8], *libc::c_void),
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
uv_async_send([u8]),
uv_close([u8]),
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
uv_timer_init([u8], *libc::c_void),
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
uv_timer_call([u8]),
uv_timer_stop([u8], fn~(uv_handle)),
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
uv_end(),
uv_teardown_check()
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
type uv_loop_data = {
operation_port: comm::port<uv_operation>,
rust_loop_chan: comm::chan<uv_msg>
};
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
enum uv_loop {
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
uv_loop_new(comm::chan<uv_msg>, *libc::c_void)
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
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
// libuv struct mappings
type uv_ip4_addr = {
ip: [u8],
port: int
};
type uv_ip6_addr = uv_ip4_addr;
enum uv_handle_type {
UNKNOWN_HANDLE = 0,
UV_TCP,
UV_UDP,
UV_NAMED_PIPE,
UV_TTY,
UV_FILE,
UV_TIMER,
UV_PREPARE,
UV_CHECK,
UV_IDLE,
UV_ASYNC,
UV_ARES_TASK,
UV_ARES_EVENT,
UV_PROCESS,
UV_FS_EVENT
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
type handle_type = libc::c_uint;
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
type uv_handle_fields = {
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
loop_handle: *libc::c_void,
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
type_: handle_type,
close_cb: *u8,
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
mut data: *libc::c_void,
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
};
// unix size: 8
type uv_err_t = {
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
code: libc::c_int,
sys_errno_: libc::c_int
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
};
// don't create one of these directly. instead,
// count on it appearing in libuv callbacks or embedded
// in other types as a pointer to be used in other
// operations (so mostly treat it as opaque, once you
// have it in this form..)
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
win32 tweaks
2012-03-27 16:28:05 -05:00
#[cfg(target_os = "win32")]
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
type uv_stream_t = {
fields: uv_handle_fields
};
// unix size: 272
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
type uv_tcp_t = {
fields: uv_handle_fields,
a00: *u8, a01: *u8, a02: *u8, a03: *u8,
a04: *u8, a05: *u8, a06: *u8, a07: *u8,
a08: *u8, a09: *u8, a10: *u8, a11: *u8,
a12: *u8, a13: *u8, a14: *u8, a15: *u8,
a16: *u8, a17: *u8, a18: *u8, a19: *u8,
a20: *u8, a21: *u8, a22: *u8, a23: *u8,
a24: *u8, a25: *u8, a26: *u8, a27: *u8,
a28: *u8, a29: *u8
};
massaging out struct-size differences between unix and win32
2012-03-28 10:34:03 -05:00
// win32 size: 240 (120)
#[cfg(target_os = "win32")]
type uv_tcp_t = {
fields: uv_handle_fields,
a00: *u8, a01: *u8, a02: *u8, a03: *u8,
a04: *u8, a05: *u8, a06: *u8, a07: *u8,
a08: *u8, a09: *u8, a10: *u8, a11: *u8,
a12: *u8, a13: *u8, a14: *u8, a15: *u8,
a16: *u8, a17: *u8, a18: *u8, a19: *u8,
a20: *u8, a21: *u8, a22: *u8, a23: *u8,
a24: *u8, a25: *u8
};
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
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
fn gen_stub_uv_tcp_t() -> uv_tcp_t {
ret { fields: { loop_handle: ptr::null(), type_: 0u32,
close_cb: ptr::null(),
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
mut data: ptr::null() },
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
a00: 0 as *u8, a01: 0 as *u8, a02: 0 as *u8, a03: 0 as *u8,
a04: 0 as *u8, a05: 0 as *u8, a06: 0 as *u8, a07: 0 as *u8,
a08: 0 as *u8, a09: 0 as *u8, a10: 0 as *u8, a11: 0 as *u8,
a12: 0 as *u8, a13: 0 as *u8, a14: 0 as *u8, a15: 0 as *u8,
a16: 0 as *u8, a17: 0 as *u8, a18: 0 as *u8, a19: 0 as *u8,
a20: 0 as *u8, a21: 0 as *u8, a22: 0 as *u8, a23: 0 as *u8,
a24: 0 as *u8, a25: 0 as *u8, a26: 0 as *u8, a27: 0 as *u8,
a28: 0 as *u8, a29: 0 as *u8
};
}
#[cfg(target_os = "win32")]
fn gen_stub_uv_tcp_t() -> uv_tcp_t {
massaging out struct-size differences between unix and win32
2012-03-28 10:34:03 -05:00
ret { fields: { loop_handle: ptr::null(), type_: 0u32,
close_cb: ptr::null(),
mut data: ptr::null() },
a00: 0 as *u8, a01: 0 as *u8, a02: 0 as *u8, a03: 0 as *u8,
a04: 0 as *u8, a05: 0 as *u8, a06: 0 as *u8, a07: 0 as *u8,
a08: 0 as *u8, a09: 0 as *u8, a10: 0 as *u8, a11: 0 as *u8,
a12: 0 as *u8, a13: 0 as *u8, a14: 0 as *u8, a15: 0 as *u8,
a16: 0 as *u8, a17: 0 as *u8, a18: 0 as *u8, a19: 0 as *u8,
a20: 0 as *u8, a21: 0 as *u8, a22: 0 as *u8, a23: 0 as *u8,
a24: 0 as *u8, a25: 0 as *u8
};
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
}
// unix size: 48
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
type uv_connect_t = {
a00: *u8, a01: *u8, a02: *u8, a03: *u8,
a04: *u8, a05: *u8
};
massaging out struct-size differences between unix and win32
2012-03-28 10:34:03 -05:00
// win32 size: 88 (44)
#[cfg(target_os = "win32")]
type uv_connect_t = {
a00: *u8, a01: *u8, a02: *u8, a03: *u8,
a04: *u8, a05: *u8, a06: *u8, a07: *u8,
a08: *u8, a09: *u8, a10: *u8
};
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
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
fn gen_stub_uv_connect_t() -> uv_connect_t {
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
ret {
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
a00: 0 as *u8, a01: 0 as *u8, a02: 0 as *u8, a03: 0 as *u8,
massaging out struct-size differences between unix and win32
2012-03-28 10:34:03 -05:00
a01: 0 as *u8, a05: 0 as *u8
};
}
#[cfg(target_os = "win32")]
fn gen_stub_uv_connect_t() -> uv_connect_t {
ret {
a00: 0 as *u8, a01: 0 as *u8, a02: 0 as *u8, a03: 0 as *u8,
a04: 0 as *u8, a05: 0 as *u8, a06: 0 as *u8, a07: 0 as *u8,
a08: 0 as *u8, a09: 0 as *u8, a10: 0 as *u8
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
};
}
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
// ref #1402 .. don't use this, like sockaddr_in
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
// unix size: 16
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
win32 tweaks
2012-03-27 16:28:05 -05:00
#[cfg(target_os = "win32")]
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
type uv_buf_t = {
base: *u8,
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
len: libc::size_t
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
};
// no gen stub method.. should create
// it via uv::direct::buf_init()
// unix size: 144
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
type uv_write_t = {
fields: uv_handle_fields,
a00: *u8, a01: *u8, a02: *u8, a03: *u8,
a04: *u8, a05: *u8, a06: *u8, a07: *u8,
a08: *u8, a09: *u8, a10: *u8, a11: *u8,
a12: *u8, a13: *u8
};
massaging out struct-size differences between unix and win32
2012-03-28 10:34:03 -05:00
// win32 size: 136 (68)
#[cfg(target_os = "win32")]
type uv_write_t = {
fields: uv_handle_fields,
a00: *u8, a01: *u8, a02: *u8, a03: *u8,
a04: *u8, a05: *u8, a06: *u8, a07: *u8,
a08: *u8, a09: *u8, a10: *u8, a11: *u8,
a12: *u8
};
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
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
fn gen_stub_uv_write_t() -> uv_write_t {
ret { fields: { loop_handle: ptr::null(), type_: 0u32,
close_cb: ptr::null(),
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
mut data: ptr::null() },
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
a00: 0 as *u8, a01: 0 as *u8, a02: 0 as *u8, a03: 0 as *u8,
a04: 0 as *u8, a05: 0 as *u8, a06: 0 as *u8, a07: 0 as *u8,
a08: 0 as *u8, a09: 0 as *u8, a10: 0 as *u8, a11: 0 as *u8,
a12: 0 as *u8, a13: 0 as *u8
};
}
massaging out struct-size differences between unix and win32
2012-03-28 10:34:03 -05:00
#[cfg(target_os = "win32")]
fn gen_stub_uv_write_t() -> uv_write_t {
ret { fields: { loop_handle: ptr::null(), type_: 0u32,
close_cb: ptr::null(),
mut data: ptr::null() },
a00: 0 as *u8, a01: 0 as *u8, a02: 0 as *u8, a03: 0 as *u8,
a04: 0 as *u8, a05: 0 as *u8, a06: 0 as *u8, a07: 0 as *u8,
a08: 0 as *u8, a09: 0 as *u8, a10: 0 as *u8, a11: 0 as *u8,
a12: 0 as *u8
};
}
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
// unix size: 16
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
win32 tweaks
2012-03-27 16:28:05 -05:00
#[cfg(target_os = "win32")]
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
type sockaddr_in = {
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
mut sin_family: u16,
mut sin_port: u16,
mut sin_addr: u32, // in_addr: this is an opaque, per-platform struct
mut sin_zero: (u8, u8, u8, u8, u8, u8, u8, u8)
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
};
// unix size: 28 .. make due w/ 32
win32 tweaks
2012-03-27 16:28:05 -05:00
#[cfg(target_os = "linux")]
#[cfg(target_os = "macos")]
#[cfg(target_os = "freebsd")]
#[cfg(target_os = "win32")]
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
type sockaddr_in6 = {
a0: *u8, a1: *u8,
a2: *u8, a3: *u8
};
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
#[nolink]
native mod rustrt {
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
fn rust_uv_loop_new() -> *libc::c_void;
fn rust_uv_loop_delete(lp: *libc::c_void);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn rust_uv_loop_set_data(
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
lp: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
data: *uv_loop_data);
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
fn rust_uv_bind_op_cb(lp: *libc::c_void, cb: *u8)
-> *libc::c_void;
fn rust_uv_stop_op_cb(handle: *libc::c_void);
fn rust_uv_run(loop_handle: *libc::c_void);
fn rust_uv_close(handle: *libc::c_void, cb: *u8);
fn rust_uv_close_async(handle: *libc::c_void);
fn rust_uv_close_timer(handle: *libc::c_void);
fn rust_uv_async_send(handle: *libc::c_void);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn rust_uv_async_init(
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
loop_handle: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
cb: *u8,
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
id: *u8) -> *libc::c_void;
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn rust_uv_timer_init(
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
loop_handle: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
cb: *u8,
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
id: *u8) -> *libc::c_void;
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn rust_uv_timer_start(
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
timer_handle: *libc::c_void,
timeout: libc::c_uint,
repeat: libc::c_uint);
fn rust_uv_timer_stop(handle: *libc::c_void);
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
fn rust_uv_free(ptr: *libc::c_void);
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
fn rust_uv_tcp_init(
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
loop_handle: *libc::c_void,
handle_ptr: *uv_tcp_t) -> libc::c_int;
fn rust_uv_buf_init(base: *u8, len: libc::size_t)
uv_buf_t's for uv_write() passed by-val .. no more mallocs or ptr cop-outs so we're now adhering the libuv C api and passing structs by-val where it is expected, instead of pulling pointer trickery (or worse having to malloc structs in c++ to be passed back to rust and then into C again)
2012-03-22 23:49:48 -05:00
-> uv_buf_t;
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
fn rust_uv_last_error(loop_handle: *libc::c_void) -> uv_err_t;
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
fn rust_uv_ip4_test_verify_port_val(++addr: sockaddr_in,
expected: libc::c_uint)
-> bool;
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
fn rust_uv_ip4_addr(ip: *u8, port: libc::c_int)
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
-> sockaddr_in;
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
fn rust_uv_tcp_connect(connect_ptr: *uv_connect_t,
tcp_handle_ptr: *uv_tcp_t,
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
++addr: sockaddr_in,
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
after_cb: *u8) -> libc::c_int;
fn rust_uv_write(req: *libc::c_void, stream: *libc::c_void,
uv_buf_t's for uv_write() passed by-val .. no more mallocs or ptr cop-outs so we're now adhering the libuv C api and passing structs by-val where it is expected, instead of pulling pointer trickery (or worse having to malloc structs in c++ to be passed back to rust and then into C again)
2012-03-22 23:49:48 -05:00
++buf_in: *uv_buf_t, buf_cnt: libc::c_int,
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
cb: *u8) -> libc::c_int;
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
fn rust_uv_read_start(stream: *libc::c_void, on_alloc: *u8,
on_read: *u8) -> libc::c_int;
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
fn rust_uv_read_stop(stream: *libc::c_void) -> libc::c_int;
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
fn rust_uv_malloc_buf_base_of(sug_size: libc::size_t) -> *u8;
fn rust_uv_free_base_of_buf(++buf: uv_buf_t);
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
// sizeof testing helpers
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
fn rust_uv_helper_uv_tcp_t_size() -> libc::c_uint;
fn rust_uv_helper_uv_connect_t_size() -> libc::c_uint;
fn rust_uv_helper_uv_buf_t_size() -> libc::c_uint;
fn rust_uv_helper_uv_write_t_size() -> libc::c_uint;
fn rust_uv_helper_uv_err_t_size() -> libc::c_uint;
fn rust_uv_helper_sockaddr_in_size() -> libc::c_uint;
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
// data accessors for rust-mapped uv structs
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
fn rust_uv_get_stream_handle_from_connect_req(
connect_req: *uv_connect_t)
-> *uv_stream_t;
fn rust_uv_get_stream_handle_from_write_req(
write_req: *uv_write_t)
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
-> *uv_stream_t;
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
fn rust_uv_get_loop_for_uv_handle(handle: *libc::c_void)
-> *libc::c_void;
fn rust_uv_get_data_for_uv_handle(handle: *libc::c_void)
-> *libc::c_void;
fn rust_uv_set_data_for_uv_handle(handle: *libc::c_void,
data: *libc::c_void);
fn rust_uv_get_data_for_req(req: *libc::c_void) -> *libc::c_void;
fn rust_uv_set_data_for_req(req: *libc::c_void,
data: *libc::c_void);
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
fn rust_uv_get_base_from_buf(++buf: uv_buf_t) -> *u8;
fn rust_uv_get_len_from_buf(++buf: uv_buf_t) -> libc::size_t;
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
}
// this module is structured around functions that directly
// expose libuv functionality and data structures. for use
// in higher level mappings
mod direct {
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn loop_new() -> *libc::c_void {
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
ret rustrt::rust_uv_loop_new();
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn loop_delete(loop_handle: *libc::c_void) {
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
rustrt::rust_uv_loop_delete(loop_handle);
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn run(loop_handle: *libc::c_void) {
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
rustrt::rust_uv_run(loop_handle);
}
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
unsafe fn close(handle: *libc::c_void, cb: *u8) {
rustrt::rust_uv_close(handle, cb);
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn tcp_init(loop_handle: *libc::c_void, handle: *uv_tcp_t)
-> libc::c_int {
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
ret rustrt::rust_uv_tcp_init(loop_handle, handle);
}
unsafe fn tcp_connect(connect_ptr: *uv_connect_t,
tcp_handle_ptr: *uv_tcp_t,
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
address: sockaddr_in,
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
after_connect_cb: *u8)
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
-> libc::c_int {
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
io::println(#fmt("b4 native tcp_connect--addr port: %u",
address.sin_port as uint));
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
ret rustrt::rust_uv_tcp_connect(connect_ptr, tcp_handle_ptr,
address, after_connect_cb);
}
fixed passing in uv_buf_t ptr array in uv_write.. return status 0 ways to go, still..
2012-03-22 13:48:40 -05:00
// TODO github #1402 -- the buf_in is a vector of pointers
// to malloc'd buffers .. these will have to be translated
// back into their value types in c. sigh.
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn write(req: *libc::c_void, stream: *libc::c_void,
uv_buf_t's for uv_write() passed by-val .. no more mallocs or ptr cop-outs so we're now adhering the libuv C api and passing structs by-val where it is expected, instead of pulling pointer trickery (or worse having to malloc structs in c++ to be passed back to rust and then into C again)
2012-03-22 23:49:48 -05:00
buf_in: *[uv_buf_t], cb: *u8) -> libc::c_int {
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
let buf_ptr = vec::unsafe::to_ptr(*buf_in);
let buf_cnt = vec::len(*buf_in) as i32;
ret rustrt::rust_uv_write(req, stream, buf_ptr, buf_cnt, cb);
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
}
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
unsafe fn read_start(stream: *uv_stream_t, on_alloc: *u8,
on_read: *u8) -> libc::c_int {
ret rustrt::rust_uv_read_start(stream as *libc::c_void,
on_alloc, on_read);
}
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
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
unsafe fn read_stop(stream: *uv_stream_t) -> libc::c_int {
ret rustrt::rust_uv_read_stop(stream as *libc::c_void);
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn uv_last_error(loop_handle: *libc::c_void) -> uv_err_t {
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
ret rustrt::rust_uv_last_error(loop_handle);
}
// libuv struct initializers
unsafe fn tcp_t() -> uv_tcp_t {
ret gen_stub_uv_tcp_t();
}
unsafe fn connect_t() -> uv_connect_t {
ret gen_stub_uv_connect_t();
}
unsafe fn write_t() -> uv_write_t {
ret gen_stub_uv_write_t();
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn get_loop_for_uv_handle(handle: *libc::c_void)
-> *libc::c_void {
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
ret rustrt::rust_uv_get_loop_for_uv_handle(handle);
}
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
unsafe fn get_stream_handle_from_connect_req(connect: *uv_connect_t)
-> *uv_stream_t {
ret rustrt::rust_uv_get_stream_handle_from_connect_req(
connect);
}
unsafe fn get_stream_handle_from_write_req(
write_req: *uv_write_t)
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
-> *uv_stream_t {
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
ret rustrt::rust_uv_get_stream_handle_from_write_req(
write_req);
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
}
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
unsafe fn get_data_for_uv_handle(handle: *libc::c_void) -> *libc::c_void {
ret rustrt::rust_uv_get_data_for_uv_handle(handle);
}
unsafe fn set_data_for_uv_handle(handle: *libc::c_void,
data: *libc::c_void) {
rustrt::rust_uv_set_data_for_uv_handle(handle, data);
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn get_data_for_req(req: *libc::c_void) -> *libc::c_void {
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
ret rustrt::rust_uv_get_data_for_req(req);
}
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
unsafe fn set_data_for_req(req: *libc::c_void,
data: *libc::c_void) {
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
rustrt::rust_uv_set_data_for_req(req, data);
}
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
unsafe fn get_base_from_buf(buf: uv_buf_t) -> *u8 {
ret rustrt::rust_uv_get_base_from_buf(buf);
}
unsafe fn get_len_from_buf(buf: uv_buf_t) -> libc::size_t {
ret rustrt::rust_uv_get_len_from_buf(buf);
}
uv_buf_t's for uv_write() passed by-val .. no more mallocs or ptr cop-outs so we're now adhering the libuv C api and passing structs by-val where it is expected, instead of pulling pointer trickery (or worse having to malloc structs in c++ to be passed back to rust and then into C again)
2012-03-22 23:49:48 -05:00
unsafe fn buf_init(input: *u8, len: uint) -> uv_buf_t {
some more stuff for libuv dealing w/ 1402.. should go away soon
2012-03-21 10:56:05 -05:00
ret rustrt::rust_uv_buf_init(input, len);
}
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
unsafe fn ip4_addr(ip: str, port: int)
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
-> sockaddr_in {
let mut addr_vec = str::bytes(ip);
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
addr_vec += [0u8]; // add null terminator
let addr_vec_ptr = vec::unsafe::to_ptr(addr_vec);
let ip_back = str::from_bytes(addr_vec);
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
io::println(#fmt("vec val: '%s' length: %u",
ip_back, vec::len(addr_vec)));
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
ret rustrt::rust_uv_ip4_addr(addr_vec_ptr,
port as libc::c_int);
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
}
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
unsafe fn malloc_buf_base_of(suggested_size: libc::size_t)
-> *u8 {
ret rustrt::rust_uv_malloc_buf_base_of(suggested_size);
}
unsafe fn free_base_of_buf(buf: uv_buf_t) {
rustrt::rust_uv_free_base_of_buf(buf);
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
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// public functions
fn loop_new() -> uv_loop unsafe {
let ret_recv_port: comm::port<uv_loop> =
comm::port();
let ret_recv_chan: comm::chan<uv_loop> =
comm::chan(ret_recv_port);
changing rust loop to 1 thread
2012-02-26 14:11:30 -06:00
task::spawn_sched(task::manual_threads(1u)) {||
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// our beloved uv_loop_t ptr
let loop_handle = rustrt::
rust_uv_loop_new();
// this port/chan pair are used to send messages to
// libuv. libuv processes any pending messages on the
// port (via crust) after receiving an async "wakeup"
// on a special uv_async_t handle created below
let operation_port = comm::port::<uv_operation>();
let operation_chan = comm::chan::<uv_operation>(
operation_port);
// this port/chan pair as used in the while() loop
// below. It takes dispatches, originating from libuv
// callbacks, to invoke handles registered by the
// user
let rust_loop_port = comm::port::<uv_msg>();
let rust_loop_chan =
comm::chan::<uv_msg>(rust_loop_port);
// let the task-spawner return
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
let user_uv_loop = uv_loop_new(rust_loop_chan, loop_handle);
comm::send(ret_recv_chan, copy(user_uv_loop));
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// create our "special" async handle that will
// allow all operations against libuv to be
// "buffered" in the operation_port, for processing
// from the thread that libuv runs on
let loop_data: uv_loop_data = {
operation_port: operation_port,
rust_loop_chan: rust_loop_chan
};
rustrt::rust_uv_loop_set_data(
loop_handle,
ptr::addr_of(loop_data)); // pass an opaque C-ptr
// to libuv, this will be
// in the process_operation
// crust fn
let op_handle = rustrt::rust_uv_bind_op_cb(
loop_handle,
process_operation);
// all state goes here
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
let handles: map::hashmap<[u8], *libc::c_void> =
std: Rename the hashmap constructors to conform to new standards Instead of using the new_ prefix just name them after their type
2012-03-14 14:07:23 -05:00
map::bytes_hash();
stdlib: Stop incurring vtable dispatch costs when hashmaps are used This required changing almost all users of hashmaps to import the hashmap interface first. The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
2012-03-07 18:48:57 -06:00
let id_to_handle: map::hashmap<[u8], uv_handle> =
std: Rename the hashmap constructors to conform to new standards Instead of using the new_ prefix just name them after their type
2012-03-14 14:07:23 -05:00
map::bytes_hash();
stdlib: Stop incurring vtable dispatch costs when hashmaps are used This required changing almost all users of hashmaps to import the hashmap interface first. The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
2012-03-07 18:48:57 -06:00
let after_cbs: map::hashmap<[u8], fn~(uv_handle)> =
std: Rename the hashmap constructors to conform to new standards Instead of using the new_ prefix just name them after their type
2012-03-14 14:07:23 -05:00
map::bytes_hash();
stdlib: Stop incurring vtable dispatch costs when hashmaps are used This required changing almost all users of hashmaps to import the hashmap interface first. The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
2012-03-07 18:48:57 -06:00
let close_callbacks: map::hashmap<[u8], fn~()> =
std: Rename the hashmap constructors to conform to new standards Instead of using the new_ prefix just name them after their type
2012-03-14 14:07:23 -05:00
map::bytes_hash();
stdlib: Stop incurring vtable dispatch costs when hashmaps are used This required changing almost all users of hashmaps to import the hashmap interface first. The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
2012-03-07 18:48:57 -06:00
let async_cbs: map::hashmap<[u8], fn~(uv_handle)> =
std: Rename the hashmap constructors to conform to new standards Instead of using the new_ prefix just name them after their type
2012-03-14 14:07:23 -05:00
map::bytes_hash();
stdlib: Stop incurring vtable dispatch costs when hashmaps are used This required changing almost all users of hashmaps to import the hashmap interface first. The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
2012-03-07 18:48:57 -06:00
let timer_cbs: map::hashmap<[u8], fn~(uv_handle)> =
std: Rename the hashmap constructors to conform to new standards Instead of using the new_ prefix just name them after their type
2012-03-14 14:07:23 -05:00
map::bytes_hash();
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// the main loop that this task blocks on.
// should have the same lifetime as the C libuv
// event loop.
annotate libstd and start enforcing mutability
2012-03-14 13:03:56 -05:00
let mut keep_going = true;
while keep_going {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
alt comm::recv(rust_loop_port) {
msg_run(end_chan) {
// start the libuv event loop
// we'll also do a uv_async_send with
// the operation handle to have the
// loop process any pending operations
// once its up and running
task::spawn_sched(task::manual_threads(1u)) {||
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
// make sure we didn't start the loop
// without the user registering handles
comm::send(rust_loop_chan, uv_teardown_check);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// this call blocks
rustrt::rust_uv_run(loop_handle);
// when we're done, msg the
// end chan
comm::send(end_chan, true);
comm::send(rust_loop_chan, uv_end);
};
}
msg_run_in_bg {
task::spawn_sched(task::manual_threads(1u)) {||
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
// see note above
comm::send(rust_loop_chan, uv_teardown_check);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// this call blocks
rustrt::rust_uv_run(loop_handle);
};
}
msg_close(handle, cb) {
let id = get_id_from_handle(handle);
close_callbacks.insert(id, cb);
let handle_ptr = handles.get(id);
let op = op_close(handle, handle_ptr);
pass_to_libuv(op_handle, operation_chan, op);
}
uv_close(id) {
handles.remove(id);
let handle = id_to_handle.get(id);
id_to_handle.remove(id);
alt handle {
uv_async(id, _) {
async_cbs.remove(id);
}
uv_timer(id, _) {
timer_cbs.remove(id);
}
_ {
fail "unknown form of uv_handle encountered "
+ "in uv_close handler";
}
}
let cb = close_callbacks.get(id);
close_callbacks.remove(id);
task::spawn {||
cb();
};
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
// ask the rust loop to check and see if there
// are no more user-registered handles
comm::send(rust_loop_chan, uv_teardown_check);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
msg_async_init(callback, after_cb) {
// create a new async handle
// with the id as the handle's
// data and save the callback for
// invocation on msg_async_send
let id = gen_handle_id();
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
handles.insert(id, ptr::null());
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
async_cbs.insert(id, callback);
after_cbs.insert(id, after_cb);
let op = op_async_init(id);
pass_to_libuv(op_handle, operation_chan, op);
}
uv_async_init(id, async_handle) {
// libuv created a handle, which is
// passed back to us. save it and
// then invoke the supplied callback
// for after completion
handles.insert(id, async_handle);
let after_cb = after_cbs.get(id);
after_cbs.remove(id);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
let async = uv_async(id, user_uv_loop);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
id_to_handle.insert(id, copy(async));
task::spawn {||
after_cb(async);
};
}
msg_async_send(id) {
let async_handle = handles.get(id);
do_send(async_handle);
}
uv_async_send(id) {
let async_cb = async_cbs.get(id);
task::spawn {||
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
let the_loop = user_uv_loop;
async_cb(uv_async(id, the_loop));
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
};
}
msg_timer_init(after_cb) {
let id = gen_handle_id();
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
handles.insert(id, ptr::null());
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
after_cbs.insert(id, after_cb);
let op = op_timer_init(id);
pass_to_libuv(op_handle, operation_chan, op);
}
uv_timer_init(id, handle) {
handles.insert(id, handle);
let after_cb = after_cbs.get(id);
after_cbs.remove(id);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
let new_timer = uv_timer(id, user_uv_loop);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
id_to_handle.insert(id, copy(new_timer));
task::spawn {||
after_cb(new_timer);
};
}
uv_timer_call(id) {
let cb = timer_cbs.get(id);
let the_timer = id_to_handle.get(id);
task::spawn {||
cb(the_timer);
};
}
msg_timer_start(id, timeout, repeat, timer_call_cb) {
timer_cbs.insert(id, timer_call_cb);
let handle = handles.get(id);
let op = op_timer_start(id, handle, timeout,
repeat);
pass_to_libuv(op_handle, operation_chan, op);
}
msg_timer_stop(id, after_cb) {
let handle = handles.get(id);
let op = op_timer_stop(id, handle, after_cb);
pass_to_libuv(op_handle, operation_chan, op);
}
uv_timer_stop(id, after_cb) {
let the_timer = id_to_handle.get(id);
after_cb(the_timer);
}
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
uv_teardown_check() {
// here we're checking if there are no user-registered
// handles (and the loop is running), if this is the
// case, then we need to unregister the op_handle via
// a uv_close() call, thus allowing libuv to return
// on its own.
if (handles.size() == 0u) {
let op = op_teardown(op_handle);
pass_to_libuv(op_handle, operation_chan, op);
}
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
uv_end() {
keep_going = false;
}
_ { fail "unknown form of uv_msg received"; }
}
}
};
ret comm::recv(ret_recv_port);
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
fn loop_delete(lp: uv_loop) {
let loop_ptr = get_loop_ptr_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
rustrt::rust_uv_loop_delete(loop_ptr);
}
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
fn run(lp: uv_loop) {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
let end_port = comm::port::<bool>();
let end_chan = comm::chan::<bool>(end_port);
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
let loop_chan = get_loop_chan_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
comm::send(loop_chan, msg_run(end_chan));
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
comm::recv(end_port);
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
fn run_in_bg(lp: uv_loop) {
let loop_chan = get_loop_chan_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
comm::send(loop_chan, msg_run_in_bg);
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn async_init (
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
lp: uv_loop,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
async_cb: fn~(uv_handle),
after_cb: fn~(uv_handle)) {
allow immut vars to be moved. enforce mut vars after stage0 in std.
2012-03-14 17:28:50 -05:00
let msg = msg_async_init(async_cb, after_cb);
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
let loop_chan = get_loop_chan_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
comm::send(loop_chan, msg);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn async_send(async: uv_handle) {
alt async {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_async(id, lp) {
let loop_chan = get_loop_chan_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
comm::send(loop_chan, msg_async_send(id));
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
_ {
fail "attempting to call async_send() with a" +
" uv_async uv_handle";
}
}
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn close(h: uv_handle, cb: fn~()) {
let loop_chan = get_loop_chan_from_handle(h);
comm::send(loop_chan, msg_close(h, cb));
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
fn timer_init(lp: uv_loop, after_cb: fn~(uv_handle)) {
allow immut vars to be moved. enforce mut vars after stage0 in std.
2012-03-14 17:28:50 -05:00
let msg = msg_timer_init(after_cb);
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
let loop_chan = get_loop_chan_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
comm::send(loop_chan, msg);
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn timer_start(the_timer: uv_handle, timeout: u32, repeat:u32,
timer_cb: fn~(uv_handle)) {
alt the_timer {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_timer(id, lp) {
allow immut vars to be moved. enforce mut vars after stage0 in std.
2012-03-14 17:28:50 -05:00
let msg = msg_timer_start(id, timeout, repeat, timer_cb);
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
let loop_chan = get_loop_chan_from_uv_loop(lp);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
comm::send(loop_chan, msg);
}
_ {
fail "can only pass a uv_timer form of uv_handle to "+
" uv::timer_start()";
}
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn timer_stop(the_timer: uv_handle, after_cb: fn~(uv_handle)) {
alt the_timer {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_timer(id, lp) {
let loop_chan = get_loop_chan_from_uv_loop(lp);
allow immut vars to be moved. enforce mut vars after stage0 in std.
2012-03-14 17:28:50 -05:00
let msg = msg_timer_stop(id, after_cb);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
comm::send(loop_chan, msg);
}
_ {
fail "only uv_timer form is allowed in calls to "+
" uv::timer_stop()";
}
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// internal functions
fn pass_to_libuv(
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
op_handle: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
operation_chan: comm::chan<uv_operation>,
op: uv_operation) unsafe {
comm::send(operation_chan, copy(op));
do_send(op_handle);
}
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
fn do_send(h: *libc::c_void) {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
rustrt::rust_uv_async_send(h);
}
fn gen_handle_id() -> [u8] {
Overhaul constructor naming in libs
2012-03-12 17:52:30 -05:00
ret rand::rng().gen_bytes(16u);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
fn get_handle_id_from(buf: *u8) -> [u8] unsafe {
ret vec::unsafe::from_buf(buf, 16u);
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn get_loop_chan_from_data(data: *uv_loop_data)
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
-> comm::chan<uv_msg> unsafe {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
ret (*data).rust_loop_chan;
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn get_loop_chan_from_handle(handle: uv_handle)
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
-> comm::chan<uv_msg> {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
alt handle {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_async(id,lp) | uv_timer(id,lp) {
let loop_chan = get_loop_chan_from_uv_loop(lp);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
ret loop_chan;
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
_ {
fail "unknown form of uv_handle for get_loop_chan_from "
+ " handle";
}
}
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
fn get_loop_ptr_from_uv_loop(lp: uv_loop) -> *libc::c_void {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
alt lp {
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv_loop_new(loop_chan, loop_ptr) {
ret loop_ptr;
}
}
}
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
fn get_loop_chan_from_uv_loop(lp: uv_loop) -> comm::chan<uv_msg> {
alt lp {
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv_loop_new(loop_chan, loop_ptr) {
ret loop_chan;
}
}
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn get_id_from_handle(handle: uv_handle) -> [u8] {
alt handle {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_async(id,lp) | uv_timer(id,lp) {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
ret id;
}
_ {
fail "unknown form of uv_handle for get_id_from handle";
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
// crust
crust fn process_operation(
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
lp: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
data: *uv_loop_data) unsafe {
let op_port = (*data).operation_port;
let loop_chan = get_loop_chan_from_data(data);
annotate libstd and start enforcing mutability
2012-03-14 13:03:56 -05:00
let mut op_pending = comm::peek(op_port);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
while(op_pending) {
alt comm::recv(op_port) {
op_async_init(id) {
let id_ptr = vec::unsafe::to_ptr(id);
let async_handle = rustrt::rust_uv_async_init(
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
lp,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
process_async_send,
id_ptr);
comm::send(loop_chan, uv_async_init(
id,
async_handle));
}
op_close(handle, handle_ptr) {
handle_op_close(handle, handle_ptr);
}
op_timer_init(id) {
let id_ptr = vec::unsafe::to_ptr(id);
let timer_handle = rustrt::rust_uv_timer_init(
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
lp,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
process_timer_call,
id_ptr);
comm::send(loop_chan, uv_timer_init(
id,
timer_handle));
}
op_timer_start(id, handle, timeout, repeat) {
rustrt::rust_uv_timer_start(handle, timeout,
repeat);
}
op_timer_stop(id, handle, after_cb) {
rustrt::rust_uv_timer_stop(handle);
comm::send(loop_chan, uv_timer_stop(id, after_cb));
}
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
op_teardown(op_handle) {
// this is the last msg that'll be processed by
// this fn, in the current lifetime of the handle's
// uv_loop_t
rustrt::rust_uv_stop_op_cb(op_handle);
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
_ { fail "unknown form of uv_operation received"; }
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
op_pending = comm::peek(op_port);
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
}
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
fn handle_op_close(handle: uv_handle, handle_ptr: *libc::c_void) {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// it's just like im doing C
alt handle {
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_async(id, lp) {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
let cb = process_close_async;
rustrt::rust_uv_close(
handle_ptr, cb);
}
Add an infinite loop construct Add a loop {} construct for infinite loops, and use it in test cases. See #1906 for details.
2012-03-09 18:11:56 -06:00
uv_timer(id, lp) {
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
let cb = process_close_timer;
rustrt::rust_uv_close(
handle_ptr, cb);
}
_ {
fail "unknown form of uv_handle encountered " +
"in process_operation/op_close";
}
stdlib: Implement some preliminary libuv bindings std::uv is intended to be low-level, exactly mirroring the C API. Difficult to continue the implementation now without scheduler improvements.
2011-12-01 01:26:23 -06:00
}
freebsd support
2011-12-30 02:18:55 -06:00
}
libstd: Move std tests into libstd
2012-01-17 21:05:07 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
crust fn process_async_send(id_buf: *u8, data: *uv_loop_data)
unsafe {
let handle_id = get_handle_id_from(id_buf);
let loop_chan = get_loop_chan_from_data(data);
comm::send(loop_chan, uv_async_send(handle_id));
}
libstd: Move std tests into libstd
2012-01-17 21:05:07 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
crust fn process_timer_call(id_buf: *u8, data: *uv_loop_data)
unsafe {
let handle_id = get_handle_id_from(id_buf);
let loop_chan = get_loop_chan_from_data(data);
comm::send(loop_chan, uv_timer_call(handle_id));
}
fn process_close_common(id: [u8], data: *uv_loop_data)
unsafe {
// notify the rust loop that their handle is closed, then
// the caller will invoke a per-handle-type c++ func to
// free allocated memory
let loop_chan = get_loop_chan_from_data(data);
comm::send(loop_chan, uv_close(id));
}
Update libuv.
2012-02-02 19:39:47 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
crust fn process_close_async(
id_buf: *u8,
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
handle_ptr: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
data: *uv_loop_data)
unsafe {
let id = get_handle_id_from(id_buf);
rustrt::rust_uv_close_async(handle_ptr);
// at this point, the handle and its data has been
// released. notify the rust loop to remove the
// handle and its data and call the user-supplied
// close cb
process_close_common(id, data);
}
Update libuv.
2012-02-02 19:39:47 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
crust fn process_close_timer(
id_buf: *u8,
Libc/os/run/rand/io reorganization. Close #1373. Close #1638. - Move io, run and rand to core. - Remove incorrect ctypes module (use libc). - Remove os-specific modules for os and fs. - Split fs between core::path and core::os.
2012-03-12 22:04:27 -05:00
handle_ptr: *libc::c_void,
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
data: *uv_loop_data)
unsafe {
let id = get_handle_id_from(id_buf);
rustrt::rust_uv_close_timer(handle_ptr);
process_close_common(id, data);
}
libstd: Move std tests into libstd
2012-01-17 21:05:07 -06:00
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
#[test]
fn test_uv_new_loop_no_handles() {
let test_loop = uv::loop_new();
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::run(test_loop); // this should return immediately
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
// since there aren't any handles..
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::loop_delete(test_loop);
libstd: Move std tests into libstd
2012-01-17 21:05:07 -06:00
}
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
#[test]
std: Ignore uv tests on FreeBSD
2012-02-28 15:56:48 -06:00
#[ignore(cfg(target_os = "freebsd"))]
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn test_uv_simple_async() {
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
let test_loop = uv::loop_new();
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
let exit_port = comm::port::<bool>();
let exit_chan = comm::chan::<bool>(exit_port);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::async_init(test_loop, {|new_async|
uv::close(new_async) {||
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
comm::send(exit_chan, true);
};
}, {|new_async|
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::async_send(new_async);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
});
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::run(test_loop);
correcting for libuv behavior that differs between linux & windows net complexity increase :/
2012-02-24 19:43:31 -06:00
let result = comm::recv(exit_port);
assert result;
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::loop_delete(test_loop);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
}
#[test]
std: Ignore uv tests on FreeBSD
2012-02-28 15:56:48 -06:00
#[ignore(cfg(target_os = "freebsd"))]
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
fn test_uv_timer() {
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
let test_loop = uv::loop_new();
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
let exit_port = comm::port::<bool>();
let exit_chan = comm::chan::<bool>(exit_port);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::timer_init(test_loop) {|new_timer|
uv::timer_start(new_timer, 1u32, 0u32) {|started_timer|
uv::timer_stop(started_timer) {|stopped_timer|
uv::close(stopped_timer) {||
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
comm::send(exit_chan, true);
};
};
};
};
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::run(test_loop);
moving new uv stuff into uv.rs and rust_uv.cpp - removing the remains of uvtmp.rs and rust_uvtmp.rs - removing the displaced, low-level libuv bindings in uv.rs and rust_uv.cpp
2012-02-22 16:00:34 -06:00
assert comm::recv(exit_port);
add uv::loop_delete() because of the last change, the loop ptr is no longer cleaned up when the loop exits. This api call addresses that. Sadly, the loop ptr is not "reusable" across multiple calls to uv::run().
2012-02-26 00:08:52 -06:00
uv::loop_delete(test_loop);
}
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
// BEGIN TCP REQUEST TEST SUITE
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
enum tcp_read_data {
tcp_read_eof,
tcp_read_more([u8]),
tcp_read_error
}
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
type request_wrapper = {
write_req: *uv_write_t,
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
req_buf: *[uv_buf_t],
read_chan: comm::chan<tcp_read_data>
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
};
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
crust fn after_close_cb(handle: *libc::c_void) {
io::println("after uv_close!");
}
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
crust fn on_alloc_cb(handle: *libc::c_void,
suggested_size: libc::size_t) -> uv_buf_t
unsafe {
io::println("on_alloc_cb!");
let char_ptr = direct::malloc_buf_base_of(suggested_size);
ret direct::buf_init(char_ptr, suggested_size);
}
crust fn on_read_cb(stream: *uv_stream_t, nread: libc::ssize_t,
++buf: uv_buf_t) unsafe {
if (nread > 0) {
// we have data
io::println(#fmt("read: data! nread: %d", nread));
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
direct::read_stop(stream);
let client_data = direct::
get_data_for_uv_handle(stream as *libc::c_void)
as *request_wrapper;
let buf_base = direct::get_base_from_buf(buf);
let buf_len = direct::get_len_from_buf(buf);
let bytes = vec::unsafe::from_buf(buf_base, buf_len);
let read_chan = (*client_data).read_chan;
comm::send(read_chan, tcp_read_more(bytes));
comm::send(read_chan, tcp_read_eof);
direct::close(stream as *libc::c_void, after_close_cb)
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
}
else if (nread == -1) {
// err .. possibly EOF
io::println("read: eof!");
}
else {
// nread == 0 .. do nothing, just free buf as below
io::println("read: do nothing!");
}
// when we're done
direct::free_base_of_buf(buf);
io::println("exiting on_read_cb");
}
crust fn on_write_complete_cb(write_req: *uv_write_t,
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
status: libc::c_int) unsafe {
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
io::println(#fmt("beginning on_write_complete_cb status: %d",
status as int));
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let stream = direct::get_stream_handle_from_write_req(write_req);
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
io::println(#fmt("on_write_complete_cb: tcp:%d write_handle:%d",
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
stream as int, write_req as int));
let result = direct::read_start(stream, on_alloc_cb, on_read_cb);
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
io::println(#fmt("ending on_write_complete_cb .. status: %d",
result as int));
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
}
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
crust fn on_connect_cb(connect_req_ptr: *uv_connect_t,
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
status: libc::c_int) unsafe {
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
io::println(#fmt("beginning on_connect_cb .. status: %d",
status as int));
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let stream =
direct::get_stream_handle_from_connect_req(connect_req_ptr);
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
if (status == 0i32) {
io::println("on_connect_cb: in status=0 if..");
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let client_data = direct::get_data_for_req(
connect_req_ptr as *libc::c_void)
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
as *request_wrapper;
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let write_handle = (*client_data).write_req as *libc::c_void;
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
io::println(#fmt("on_connect_cb: tcp stream: %d write_handle addr %d",
stream as int, write_handle as int));
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
let write_result = direct::write(write_handle,
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
stream as *libc::c_void,
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
(*client_data).req_buf,
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
on_write_complete_cb);
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
io::println(#fmt("on_connect_cb: direct::write() status: %d",
write_result as int));
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
}
else {
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
io::println("non-zero status for on_connect_cb..");
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
}
io::println("finishing on_connect_cb");
}
fn impl_uv_tcp_request() unsafe {
let test_loop = direct::loop_new();
let tcp_handle = direct::tcp_t();
let tcp_handle_ptr = ptr::addr_of(tcp_handle);
let connect_handle = direct::connect_t();
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let connect_req_ptr = ptr::addr_of(connect_handle);
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
// this is the persistent payload of data that we
// need to pass around to get this example to work.
// In C, this would be a malloc'd or stack-allocated
// struct that we'd cast to a void* and store as the
// data field in our uv_connect_t struct
let req_str = str::bytes("GET / HTTP/1.1\r\nHost: google.com"
+ "\r\n\r\n\r\n");
let req_msg_ptr: *u8 = vec::unsafe::to_ptr(req_str);
let req_msg = [
direct::buf_init(req_msg_ptr, vec::len(req_str))
];
// this is the enclosing record, we'll pass a ptr to
// this to C..
let write_handle = direct::write_t();
let write_handle_ptr = ptr::addr_of(write_handle);
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
io::println(#fmt("tcp req: tcp stream: %d write_handle: %d",
tcp_handle_ptr as int,
write_handle_ptr as int));
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let read_port = comm::port::<tcp_read_data>();
let read_chan = comm::chan::<tcp_read_data>(read_port);
let client_data = { writer_handle: write_handle_ptr,
req_buf: ptr::addr_of(req_msg),
read_chan: read_chan };
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
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
let tcp_init_result = direct::tcp_init(
changing ctypes:: to libc:: and impl of uv::direct::write()
2012-03-22 08:44:44 -05:00
test_loop as *libc::c_void, tcp_handle_ptr);
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
if (tcp_init_result == 0i32) {
io::println("sucessful tcp_init_result");
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
io::println("building addr...");
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
let addr = direct::ip4_addr("173.194.33.40", 80);
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
io::println(#fmt("after build addr in rust. port: %u",
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
addr.sin_port as uint));
//let addr: *libc::c_void = ptr::addr_of(addr_val) as
// *libc::c_void;
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
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
// this should set up the connection request..
let tcp_connect_result = direct::tcp_connect(
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
connect_req_ptr, tcp_handle_ptr,
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
addr, on_connect_cb);
if (tcp_connect_result == 0i32) {
uv_write works, buffer passing still broke, can get sockaddr_in by val .. but passing sockaddr_in by val back to C is broken, still passing by ptr .. the uv_write_cb is processed, but we have a status -1.. there is also valgrind spew.. so buf passing is broken, still.
2012-03-22 09:28:30 -05:00
// not set the data on the connect_req
// until its initialized
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
direct::set_data_for_req(
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
connect_req_ptr as *libc::c_void,
ptr::addr_of(client_data) as *libc::c_void);
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
direct::set_data_for_uv_handle(
tcp_handle_ptr as *libc::c_void,
ptr::addr_of(client_data) as *libc::c_void);
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
io::println("before run tcp req loop");
direct::run(test_loop);
io::println("after run tcp req loop");
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
// now we read from the port to get data
let mut read_bytes: [u8] = [0u8];
let mut more_data = true;
while(more_data) {
alt comm::recv(read_port) {
tcp_read_eof {
more_data = false;
}
tcp_read_more(new_bytes) {
if (vec::len(read_bytes) == 1u &&
read_bytes[0] == 0u8) {
// the "first" read.. replace
// the stubbed out vec above
// with our initial set of read
// data
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
read_bytes = new_bytes;
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
}
else {
// otherwise append
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
read_bytes += new_bytes;
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
}
}
_ {
assert false;
}
}
}
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
io::println("finished reading data, output to follow:");
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
let read_str = str::from_bytes(read_bytes);
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
io::println(read_str);
io::println(">>>>EOF<<<<");
direct::loop_delete(test_loop);
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
}
else {
io::println("direct::tcp_connect() failure");
assert false;
}
}
else {
io::println("direct::tcp_init() failure");
assert false;
}
test_uv_tcp_request() fully working on linux .. up next: windows! .. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up .. demonstrated sending data out of the uv_read_cb via a channel (which we block on to recv all of it, complete w/ EOF notification) that is read from after the loop exits. .. helpers to read the guts of a uv_buf_t .. an idea im kicking around: starting to pile up all of these hideous data accessor functions in uv::direct .. I might make impl/iface pairs for the various uv_* types that I'm using, in order to encapsulate those data access functions and, perhaps, make the access look a little cleaner (it still won't be straight field access, but it'll be a lot better) .. formatting cleanup to satisfy make check
2012-03-27 00:51:18 -05:00
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
}
// START HERE AND WORK YOUR WAY UP VIA CALLBACKS
#[test]
#[ignore(cfg(target_os = "freebsd"))]
fn test_uv_tcp_request() unsafe {
impl_uv_tcp_request();
}
// END TCP REQUEST TEST SUITE
// struct size tests
#[test]
#[ignore(cfg(target_os = "freebsd"))]
fn test_uv_struct_size_uv_tcp_t() {
let native_handle_size = rustrt::rust_uv_helper_uv_tcp_t_size();
let rust_handle_size = sys::size_of::<uv_tcp_t>();
let output = #fmt("uv_tcp_t -- native: %u rust: %u",
native_handle_size as uint, rust_handle_size);
io::println(output);
assert native_handle_size as uint == rust_handle_size;
}
#[test]
#[ignore(cfg(target_os = "freebsd"))]
fn test_uv_struct_size_uv_connect_t() {
let native_handle_size =
rustrt::rust_uv_helper_uv_connect_t_size();
let rust_handle_size = sys::size_of::<uv_connect_t>();
let output = #fmt("uv_connect_t -- native: %u rust: %u",
native_handle_size as uint, rust_handle_size);
io::println(output);
assert native_handle_size as uint == rust_handle_size;
}
#[test]
#[ignore(cfg(target_os = "freebsd"))]
fn test_uv_struct_size_uv_buf_t() {
let native_handle_size =
rustrt::rust_uv_helper_uv_buf_t_size();
let rust_handle_size = sys::size_of::<uv_buf_t>();
let output = #fmt("uv_buf_t -- native: %u rust: %u",
native_handle_size as uint, rust_handle_size);
io::println(output);
assert native_handle_size as uint == rust_handle_size;
}
#[test]
#[ignore(cfg(target_os = "freebsd"))]
fn test_uv_struct_size_uv_write_t() {
let native_handle_size =
rustrt::rust_uv_helper_uv_write_t_size();
let rust_handle_size = sys::size_of::<uv_write_t>();
let output = #fmt("uv_write_t -- native: %u rust: %u",
native_handle_size as uint, rust_handle_size);
io::println(output);
assert native_handle_size as uint == rust_handle_size;
}
#[test]
#[ignore(cfg(target_os = "freebsd"))]
fn test_uv_struct_size_sockaddr_in() {
let native_handle_size =
rustrt::rust_uv_helper_sockaddr_in_size();
let rust_handle_size = sys::size_of::<sockaddr_in>();
let output = #fmt("sockaddr_in -- native: %u rust: %u",
native_handle_size as uint, rust_handle_size);
io::println(output);
assert native_handle_size as uint == rust_handle_size;
}
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
fn impl_uv_byval_test() unsafe {
let addr = direct::ip4_addr("173.194.33.111", 80);
io::println(#fmt("after build addr in rust. port: %u",
addr.sin_port as uint));
assert rustrt::rust_uv_ip4_test_verify_port_val(addr,
addr.sin_port as libc::c_uint);
io::println(#fmt("after build addr in rust. port: %u",
addr.sin_port as uint));
}
#[test]
wired up uv_read_start and some helper funcs around uv_alloc_cb tasks
2012-03-26 13:09:57 -05:00
#[ignore(cfg(target_os = "freebsd"))]
fixed by-val from rust->c, use ++ sigil in native fn sig <-- NEVAR FORGET have to use ++ sigil in rust-side extern fn decls in order to have rust actually copy the struct, by value, onto the C stack. gotcha, indeed. also adding a helper method to verify/remind how to pass a struct by-val into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val() for more infos
2012-03-22 23:15:39 -05:00
fn test_uv_ip4_byval_passing_test() {
impl_uv_byval_test();
}
Reference in New Issue Copy Permalink