2012-12-10 17:44:02 -06:00
|
|
|
// Copyright 2012 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2012-04-03 19:14:28 -05:00
|
|
|
#ifdef __WIN32__
|
|
|
|
// For alloca
|
|
|
|
#include <malloc.h>
|
|
|
|
#endif
|
2012-04-02 22:18:01 -05:00
|
|
|
|
|
|
|
#include "rust_globals.h"
|
|
|
|
#include "rust_task.h"
|
2012-04-08 00:53:34 -05:00
|
|
|
#include "rust_log.h"
|
2011-12-01 01:26:23 -06:00
|
|
|
#include "uv.h"
|
|
|
|
|
2012-06-27 15:14:04 -05:00
|
|
|
// extern fn pointers
|
|
|
|
typedef void (*extern_async_op_cb)(uv_loop_t* loop, void* data,
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_async_t* op_handle);
|
2012-06-27 15:14:04 -05:00
|
|
|
typedef void (*extern_simple_cb)(uint8_t* id_buf, void* loop_data);
|
|
|
|
typedef void (*extern_close_cb)(uint8_t* id_buf, void* handle,
|
2012-04-01 23:43:39 -05:00
|
|
|
void* data);
|
2011-12-01 01:26:23 -06:00
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
// data types
|
|
|
|
#define RUST_UV_HANDLE_LEN 16
|
|
|
|
|
|
|
|
struct handle_data {
|
2012-04-01 23:43:39 -05:00
|
|
|
uint8_t id_buf[RUST_UV_HANDLE_LEN];
|
2012-06-27 15:14:04 -05:00
|
|
|
extern_simple_cb cb;
|
|
|
|
extern_close_cb close_cb;
|
2012-02-22 16:00:34 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
// helpers
|
|
|
|
static void*
|
|
|
|
current_kernel_malloc(size_t size, const char* tag) {
|
2012-04-02 00:13:39 -05:00
|
|
|
void* ptr = rust_get_current_task()->kernel->malloc(size, tag);
|
2012-02-22 16:00:34 -06:00
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
current_kernel_free(void* ptr) {
|
2012-04-02 00:13:39 -05:00
|
|
|
rust_get_current_task()->kernel->free(ptr);
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static handle_data*
|
2012-06-27 15:14:04 -05:00
|
|
|
new_handle_data_from(uint8_t* buf, extern_simple_cb cb) {
|
2012-04-01 23:43:39 -05:00
|
|
|
handle_data* data = (handle_data*)current_kernel_malloc(
|
|
|
|
sizeof(handle_data),
|
|
|
|
"handle_data");
|
|
|
|
memcpy(data->id_buf, buf, RUST_UV_HANDLE_LEN);
|
|
|
|
data->cb = cb;
|
|
|
|
return data;
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// libuv callback impls
|
|
|
|
static void
|
2012-06-27 15:14:04 -05:00
|
|
|
foreign_extern_async_op_cb(uv_async_t* handle, int status) {
|
|
|
|
extern_async_op_cb cb = (extern_async_op_cb)handle->data;
|
2012-04-01 23:43:39 -05:00
|
|
|
void* loop_data = handle->loop->data;
|
|
|
|
cb(handle->loop, loop_data, handle);
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-06-27 15:14:04 -05:00
|
|
|
foreign_async_cb(uv_async_t* handle, int status) {
|
2012-04-01 23:43:39 -05:00
|
|
|
handle_data* handle_d = (handle_data*)handle->data;
|
|
|
|
void* loop_data = handle->loop->data;
|
|
|
|
handle_d->cb(handle_d->id_buf, loop_data);
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-06-27 15:14:04 -05:00
|
|
|
foreign_timer_cb(uv_timer_t* handle, int status) {
|
2012-04-01 23:43:39 -05:00
|
|
|
handle_data* handle_d = (handle_data*)handle->data;
|
|
|
|
void* loop_data = handle->loop->data;
|
|
|
|
handle_d->cb(handle_d->id_buf, loop_data);
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-06-27 15:14:04 -05:00
|
|
|
foreign_close_cb(uv_handle_t* handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
handle_data* data = (handle_data*)handle->data;
|
|
|
|
data->close_cb(data->id_buf, handle, handle->loop->data);
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
static void
|
2012-06-27 15:14:04 -05:00
|
|
|
foreign_close_op_cb(uv_handle_t* op_handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
current_kernel_free(op_handle);
|
|
|
|
// uv_run() should return after this..
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
2012-06-27 15:14:04 -05:00
|
|
|
// foreign fns bound in rust
|
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
|
|
|
extern "C" void
|
|
|
|
rust_uv_free(void* ptr) {
|
2012-04-01 23:43:39 -05:00
|
|
|
current_kernel_free(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
|
|
|
}
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void*
|
2011-12-01 01:26:23 -06:00
|
|
|
rust_uv_loop_new() {
|
2012-02-22 16:00:34 -06:00
|
|
|
return (void*)uv_loop_new();
|
|
|
|
}
|
|
|
|
|
2012-02-26 00:08:52 -06:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_loop_delete(uv_loop_t* loop) {
|
2012-04-03 19:06:45 -05:00
|
|
|
// FIXME: This is a workaround for #1815. libev uses realloc(0) to
|
|
|
|
// free the loop, which valgrind doesn't like. We have suppressions
|
|
|
|
// to make valgrind ignore them.
|
|
|
|
//
|
|
|
|
// Valgrind also has a sanity check when collecting allocation backtraces
|
|
|
|
// that the stack pointer must be at least 512 bytes into the stack (at
|
|
|
|
// least 512 bytes of frames must have come before). When this is not
|
|
|
|
// the case it doesn't collect the backtrace.
|
|
|
|
//
|
|
|
|
// Unfortunately, with our spaghetti stacks that valgrind check triggers
|
|
|
|
// sometimes and we don't get the backtrace for the realloc(0), it
|
|
|
|
// fails to be suppressed, and it gets reported as 0 bytes lost
|
|
|
|
// from a malloc with no backtrace.
|
|
|
|
//
|
|
|
|
// This pads our stack with some extra space before deleting the loop
|
|
|
|
alloca(512);
|
2012-02-26 00:08:52 -06:00
|
|
|
uv_loop_delete(loop);
|
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_loop_set_data(uv_loop_t* loop, void* data) {
|
|
|
|
loop->data = data;
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void*
|
2012-06-27 15:14:04 -05:00
|
|
|
rust_uv_bind_op_cb(uv_loop_t* loop, extern_async_op_cb cb) {
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_async_t* async = (uv_async_t*)current_kernel_malloc(
|
|
|
|
sizeof(uv_async_t),
|
|
|
|
"uv_async_t");
|
2012-06-27 15:14:04 -05:00
|
|
|
uv_async_init(loop, async, foreign_extern_async_op_cb);
|
2012-04-01 23:43:39 -05:00
|
|
|
async->data = (void*)cb;
|
|
|
|
// decrement the ref count, so that our async bind
|
|
|
|
// doesn't count towards keeping the loop alive
|
|
|
|
//uv_unref(loop);
|
|
|
|
return async;
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_stop_op_cb(uv_handle_t* op_handle) {
|
2012-06-27 15:14:04 -05:00
|
|
|
uv_close(op_handle, foreign_close_op_cb);
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_run(uv_loop_t* loop) {
|
2013-01-30 12:28:27 -06:00
|
|
|
uv_run(loop, UV_RUN_DEFAULT);
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void
|
2012-03-29 17:11:21 -05:00
|
|
|
rust_uv_close(uv_handle_t* handle, uv_close_cb cb) {
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_close(handle, cb);
|
2012-03-29 17:11:21 -05:00
|
|
|
}
|
|
|
|
|
2013-01-30 12:28:27 -06:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_walk(uv_loop_t* loop, uv_walk_cb cb, void* arg) {
|
|
|
|
uv_walk(loop, cb, arg);
|
|
|
|
}
|
|
|
|
|
2012-03-29 17:11:21 -05:00
|
|
|
extern "C" void
|
2012-06-27 15:14:04 -05:00
|
|
|
rust_uv_hilvl_close(uv_handle_t* handle, extern_close_cb cb) {
|
2012-04-01 23:43:39 -05:00
|
|
|
handle_data* data = (handle_data*)handle->data;
|
|
|
|
data->close_cb = cb;
|
2012-06-27 15:14:04 -05:00
|
|
|
uv_close(handle, foreign_close_cb);
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void
|
2012-03-29 17:11:21 -05:00
|
|
|
rust_uv_hilvl_close_async(uv_async_t* handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
current_kernel_free(handle->data);
|
|
|
|
current_kernel_free(handle);
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void
|
2012-03-29 17:11:21 -05:00
|
|
|
rust_uv_hilvl_close_timer(uv_async_t* handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
current_kernel_free(handle->data);
|
|
|
|
current_kernel_free(handle);
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_async_send(uv_async_t* handle) {
|
|
|
|
uv_async_send(handle);
|
|
|
|
}
|
2011-12-01 01:26:23 -06:00
|
|
|
|
2012-03-30 09:19:45 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_async_init(uv_loop_t* loop_handle,
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_async_t* async_handle,
|
|
|
|
uv_async_cb cb) {
|
|
|
|
return uv_async_init(loop_handle, async_handle, cb);
|
2012-03-30 09:19:45 -05:00
|
|
|
}
|
|
|
|
|
2012-02-22 16:00:34 -06:00
|
|
|
extern "C" void*
|
2012-06-27 15:14:04 -05:00
|
|
|
rust_uv_hilvl_async_init(uv_loop_t* loop, extern_simple_cb cb,
|
2012-04-01 23:43:39 -05:00
|
|
|
uint8_t* buf) {
|
|
|
|
uv_async_t* async = (uv_async_t*)current_kernel_malloc(
|
|
|
|
sizeof(uv_async_t),
|
|
|
|
"uv_async_t");
|
2012-06-27 15:14:04 -05:00
|
|
|
uv_async_init(loop, async, foreign_async_cb);
|
2012-04-01 23:43:39 -05:00
|
|
|
handle_data* data = new_handle_data_from(buf, cb);
|
|
|
|
async->data = data;
|
2011-12-01 01:26:23 -06:00
|
|
|
|
2012-04-01 23:43:39 -05:00
|
|
|
return async;
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void*
|
2012-06-27 15:14:04 -05:00
|
|
|
rust_uv_hilvl_timer_init(uv_loop_t* loop, extern_simple_cb cb,
|
2012-04-01 23:43:39 -05:00
|
|
|
uint8_t* buf) {
|
|
|
|
uv_timer_t* new_timer = (uv_timer_t*)current_kernel_malloc(
|
|
|
|
sizeof(uv_timer_t),
|
|
|
|
"uv_timer_t");
|
|
|
|
uv_timer_init(loop, new_timer);
|
|
|
|
handle_data* data = new_handle_data_from(buf, cb);
|
|
|
|
new_timer->data = data;
|
2012-02-22 16:00:34 -06:00
|
|
|
|
2012-04-01 23:43:39 -05:00
|
|
|
return new_timer;
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
2012-04-10 16:59:53 -05:00
|
|
|
rust_uv_hilvl_timer_start(uv_timer_t* the_timer, uint32_t timeout,
|
2012-04-01 23:43:39 -05:00
|
|
|
uint32_t repeat) {
|
2012-06-27 15:14:04 -05:00
|
|
|
uv_timer_start(the_timer, foreign_timer_cb, timeout, repeat);
|
2012-02-22 16:00:34 -06:00
|
|
|
}
|
2011-12-01 01:26:23 -06:00
|
|
|
|
2012-04-10 16:59:53 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_timer_init(uv_loop_t* loop, uv_timer_t* timer) {
|
2012-04-16 15:06:41 -05:00
|
|
|
return uv_timer_init(loop, timer);
|
2012-04-10 16:59:53 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_timer_start(uv_timer_t* the_timer, uv_timer_cb cb,
|
2012-04-16 15:06:41 -05:00
|
|
|
uint32_t timeout, uint32_t repeat) {
|
2012-04-10 16:59:53 -05:00
|
|
|
return uv_timer_start(the_timer, cb, timeout, repeat);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
2012-02-22 16:00:34 -06:00
|
|
|
rust_uv_timer_stop(uv_timer_t* the_timer) {
|
2012-04-10 16:59:53 -05:00
|
|
|
return uv_timer_stop(the_timer);
|
2011-12-01 01:26:23 -06:00
|
|
|
}
|
2012-01-21 19:29:52 -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
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_init(uv_loop_t* loop, uv_tcp_t* handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return uv_tcp_init(loop, 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
|
|
|
}
|
|
|
|
|
2012-03-29 17:11:21 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_connect(uv_connect_t* connect_ptr,
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_tcp_t* tcp_ptr,
|
|
|
|
uv_connect_cb cb,
|
|
|
|
sockaddr_in* addr_ptr) {
|
|
|
|
// FIXME ref #2064
|
|
|
|
sockaddr_in addr = *addr_ptr;
|
|
|
|
int result = uv_tcp_connect(connect_ptr, tcp_ptr, addr, cb);
|
|
|
|
return result;
|
2012-03-29 17:11:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_bind(uv_tcp_t* tcp_server, sockaddr_in* addr_ptr) {
|
2012-04-01 23:43:39 -05:00
|
|
|
// FIXME ref #2064
|
|
|
|
sockaddr_in addr = *addr_ptr;
|
|
|
|
return uv_tcp_bind(tcp_server, addr);
|
2012-03-29 17:11:21 -05:00
|
|
|
}
|
2012-06-26 14:47:44 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_connect6(uv_connect_t* connect_ptr,
|
|
|
|
uv_tcp_t* tcp_ptr,
|
|
|
|
uv_connect_cb cb,
|
|
|
|
sockaddr_in6* addr_ptr) {
|
|
|
|
// FIXME ref #2064
|
|
|
|
sockaddr_in6 addr = *addr_ptr;
|
|
|
|
int result = uv_tcp_connect6(connect_ptr, tcp_ptr, addr, cb);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_bind6
|
|
|
|
(uv_tcp_t* tcp_server, sockaddr_in6* addr_ptr) {
|
|
|
|
// FIXME ref #2064
|
|
|
|
sockaddr_in6 addr = *addr_ptr;
|
|
|
|
return uv_tcp_bind6(tcp_server, addr);
|
|
|
|
}
|
2012-03-29 17:11:21 -05:00
|
|
|
|
2012-10-19 18:28:58 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_getpeername
|
|
|
|
(uv_tcp_t* handle, sockaddr_in* name) {
|
|
|
|
int namelen = sizeof(sockaddr_in);
|
|
|
|
return uv_tcp_getpeername(handle, (sockaddr*)name, &namelen);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_getpeername6
|
|
|
|
(uv_tcp_t* handle, sockaddr_in6* name) {
|
|
|
|
int namelen = sizeof(sockaddr_in6);
|
|
|
|
return uv_tcp_getpeername(handle, (sockaddr*)name, &namelen);
|
|
|
|
}
|
|
|
|
|
2012-03-29 17:11:21 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_listen(uv_stream_t* stream, int backlog,
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_connection_cb cb) {
|
|
|
|
return uv_listen(stream, backlog, cb);
|
2012-03-29 17:11:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_accept(uv_stream_t* server, uv_stream_t* client) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return uv_accept(server, client);
|
2012-03-29 17:11:21 -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
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_tcp_t_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(uv_tcp_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
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_connect_t_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(uv_connect_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
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_buf_t_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(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
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_write_t_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(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
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_err_t_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(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
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_sockaddr_in_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(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
|
|
|
}
|
2012-03-30 09:19:45 -05:00
|
|
|
extern "C" size_t
|
2012-06-12 10:38:22 -05:00
|
|
|
rust_uv_helper_sockaddr_in6_size() {
|
|
|
|
return sizeof(sockaddr_in6);
|
|
|
|
}
|
|
|
|
extern "C" size_t
|
2012-03-30 09:19:45 -05:00
|
|
|
rust_uv_helper_uv_async_t_size() {
|
2012-04-01 23:43:39 -05:00
|
|
|
return sizeof(uv_async_t);
|
2012-03-30 09:19:45 -05:00
|
|
|
}
|
2012-04-10 16:59:53 -05:00
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_timer_t_size() {
|
|
|
|
return sizeof(uv_timer_t);
|
|
|
|
}
|
2012-06-20 09:01:43 -05:00
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_addr_in_size() {
|
|
|
|
return sizeof(sockaddr_in6);
|
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_uv_getaddrinfo_t_size() {
|
|
|
|
return sizeof(uv_getaddrinfo_t);
|
|
|
|
}
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_helper_addrinfo_size() {
|
|
|
|
return sizeof(addrinfo);
|
|
|
|
}
|
2012-06-26 11:05:02 -05:00
|
|
|
extern "C" unsigned int
|
2012-06-20 09:01:43 -05:00
|
|
|
rust_uv_helper_get_INADDR_NONE() {
|
2012-06-26 08:41:18 -05:00
|
|
|
return INADDR_NONE;
|
2012-06-20 09:01:43 -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
|
|
|
extern "C" uv_stream_t*
|
2012-03-26 13:09:57 -05:00
|
|
|
rust_uv_get_stream_handle_from_connect_req(uv_connect_t* connect) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return 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
|
|
|
}
|
2012-03-26 13:09:57 -05:00
|
|
|
extern "C" uv_stream_t*
|
|
|
|
rust_uv_get_stream_handle_from_write_req(uv_write_t* write_req) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return write_req->handle;
|
2012-03-26 13:09:57 -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
|
|
|
|
2012-03-22 08:45:06 -05:00
|
|
|
extern "C" uv_buf_t
|
2012-03-21 10:56:05 -05:00
|
|
|
current_kernel_malloc_alloc_cb(uv_handle_t* handle,
|
2012-04-01 23:43:39 -05:00
|
|
|
size_t suggested_size) {
|
|
|
|
char* base_ptr = (char*)current_kernel_malloc(sizeof(char)
|
|
|
|
* suggested_size,
|
|
|
|
"uv_buf_t_base_val");
|
|
|
|
return uv_buf_init(base_ptr, suggested_size);
|
2012-03-21 10:56:05 -05:00
|
|
|
}
|
|
|
|
|
2012-04-04 02:17:19 -05:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_buf_init(uv_buf_t* out_buf, char* base, size_t len) {
|
2012-04-08 00:53:34 -05:00
|
|
|
rust_task* task = rust_get_current_task();
|
|
|
|
LOG(task, stdlib,"rust_uv_buf_init: base: %lu" \
|
2012-04-13 01:09:43 -05:00
|
|
|
"len: %lu",
|
2012-04-08 00:53:34 -05:00
|
|
|
(unsigned long int)base,
|
|
|
|
(unsigned long int)len);
|
2012-04-04 02:17:19 -05:00
|
|
|
*out_buf = uv_buf_init(base, len);
|
2012-04-08 00:53:34 -05:00
|
|
|
LOG(task, stdlib, "rust_uv_buf_init: after: "
|
2012-04-13 01:09:43 -05:00
|
|
|
"result->base: %" PRIxPTR " len: %" PRIxPTR,
|
2012-04-04 11:28:26 -05:00
|
|
|
(unsigned long int)(*out_buf).base,
|
|
|
|
(unsigned long int)(*out_buf).len);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" uv_loop_t*
|
|
|
|
rust_uv_get_loop_for_uv_handle(uv_handle_t* handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return handle->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
|
|
|
}
|
|
|
|
|
2012-04-13 01:09:43 -05:00
|
|
|
extern "C" void*
|
|
|
|
rust_uv_get_data_for_uv_loop(uv_loop_t* loop) {
|
|
|
|
return loop->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_set_data_for_uv_loop(uv_loop_t* loop,
|
|
|
|
void* data) {
|
|
|
|
loop->data = 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
|
|
|
extern "C" void*
|
|
|
|
rust_uv_get_data_for_uv_handle(uv_handle_t* handle) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return handle->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
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_set_data_for_uv_handle(uv_handle_t* handle,
|
2012-04-01 23:43:39 -05:00
|
|
|
void* data) {
|
|
|
|
handle->data = 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
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void*
|
|
|
|
rust_uv_get_data_for_req(uv_req_t* req) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return req->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
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_set_data_for_req(uv_req_t* req, void* data) {
|
2012-04-01 23:43:39 -05:00
|
|
|
req->data = 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
|
|
|
}
|
|
|
|
|
2012-03-26 13:09:57 -05:00
|
|
|
extern "C" char*
|
|
|
|
rust_uv_get_base_from_buf(uv_buf_t buf) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return buf.base;
|
2012-03-26 13:09:57 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" size_t
|
|
|
|
rust_uv_get_len_from_buf(uv_buf_t buf) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return buf.len;
|
2012-03-26 13:09:57 -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
|
|
|
extern "C" uv_err_t
|
|
|
|
rust_uv_last_error(uv_loop_t* loop) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return uv_last_error(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
|
|
|
}
|
2012-03-22 08:45:06 -05:00
|
|
|
|
2012-04-01 15:13:18 -05:00
|
|
|
extern "C" const char*
|
|
|
|
rust_uv_strerror(uv_err_t* err_ptr) {
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_err_t err = *err_ptr;
|
|
|
|
return uv_strerror(err);
|
2012-04-01 15:13:18 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" const char*
|
|
|
|
rust_uv_err_name(uv_err_t* err_ptr) {
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_err_t err = *err_ptr;
|
|
|
|
return uv_err_name(err);
|
2012-04-01 15:13:18 -05:00
|
|
|
}
|
|
|
|
|
2012-03-22 08:45:06 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_write(uv_write_t* req, uv_stream_t* handle,
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_buf_t* bufs, int buf_cnt,
|
|
|
|
uv_write_cb cb) {
|
|
|
|
return uv_write(req, handle, bufs, 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
|
|
|
}
|
2012-03-26 13:09:57 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_read_start(uv_stream_t* stream, uv_alloc_cb on_alloc,
|
2012-04-01 23:43:39 -05:00
|
|
|
uv_read_cb on_read) {
|
2012-03-26 13:09:57 -05:00
|
|
|
return uv_read_start(stream, on_alloc, on_read);
|
|
|
|
}
|
|
|
|
|
2012-03-27 00:51:18 -05:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_read_stop(uv_stream_t* stream) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return uv_read_stop(stream);
|
2012-03-27 00:51:18 -05:00
|
|
|
}
|
|
|
|
|
2012-03-26 13:09:57 -05:00
|
|
|
extern "C" char*
|
|
|
|
rust_uv_malloc_buf_base_of(size_t suggested_size) {
|
2012-04-01 23:43:39 -05:00
|
|
|
return (char*) current_kernel_malloc(sizeof(char)*suggested_size,
|
|
|
|
"uv_buf_t base");
|
2012-03-26 13:09:57 -05:00
|
|
|
}
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_free_base_of_buf(uv_buf_t buf) {
|
2012-04-01 23:43:39 -05:00
|
|
|
current_kernel_free(buf.base);
|
2012-03-26 13:09:57 -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
|
|
|
|
2012-03-22 23:15:39 -05:00
|
|
|
extern "C" struct 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
|
|
|
rust_uv_ip4_addr(const char* ip, int port) {
|
2012-04-08 00:53:34 -05:00
|
|
|
rust_task* task = rust_get_current_task();
|
|
|
|
LOG(task, stdlib, "before creating addr_ptr.. ip %s" \
|
2012-06-27 17:28:03 -05:00
|
|
|
" port %d\n", ip, port);
|
2012-04-01 23:43:39 -05:00
|
|
|
struct sockaddr_in addr = uv_ip4_addr(ip, port);
|
2012-04-13 01:09:43 -05:00
|
|
|
LOG(task, stdlib, "after creating .. port: %d", addr.sin_port);
|
2012-04-01 23:43:39 -05:00
|
|
|
return addr;
|
2012-03-22 23:15:39 -05:00
|
|
|
}
|
2012-06-12 10:38:22 -05:00
|
|
|
extern "C" struct sockaddr_in6
|
|
|
|
rust_uv_ip6_addr(const char* ip, int port) {
|
|
|
|
rust_task* task = rust_get_current_task();
|
|
|
|
LOG(task, stdlib, "before creating addr_ptr.. ip %s" \
|
2012-06-27 17:28:03 -05:00
|
|
|
" port %d\n", ip, port);
|
|
|
|
return uv_ip6_addr(ip, port);
|
2012-06-12 10:38:22 -05:00
|
|
|
}
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_ip4_name(struct sockaddr_in* src, char* dst, size_t size) {
|
2012-06-26 08:41:18 -05:00
|
|
|
return uv_ip4_name(src, dst, size);
|
2012-06-12 10:38:22 -05:00
|
|
|
}
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_ip6_name(struct sockaddr_in6* src, char* dst, size_t size) {
|
2012-06-27 17:28:03 -05:00
|
|
|
int result = uv_ip6_name(src, dst, size);
|
|
|
|
return result;
|
2012-06-12 10:38:22 -05:00
|
|
|
}
|
2012-10-19 18:28:58 -05:00
|
|
|
extern "C" unsigned int
|
|
|
|
rust_uv_ip4_port(struct sockaddr_in* src) {
|
|
|
|
return ntohs(src->sin_port);
|
|
|
|
}
|
|
|
|
extern "C" unsigned int
|
|
|
|
rust_uv_ip6_port(struct sockaddr_in6* src) {
|
|
|
|
return ntohs(src->sin6_port);
|
|
|
|
}
|
2012-04-12 00:14:16 -05:00
|
|
|
|
2012-05-14 09:01:23 -05:00
|
|
|
extern "C" void*
|
|
|
|
rust_uv_current_kernel_malloc(size_t size) {
|
std: splitting out tcp server API + tests
- we now have two interfaces for the TCP/IP server/listener workflow,
based on different user approaches surrounding how to deal with the
flow of accept a new tcp connection:
1. the "original" API closely mimics the low-level libuv API, in that we
have an on_connect_cb that the user provides *that is ran on the libuv
thread*. In this callback, the user can accept() a connection, turning it
into a tcp_socket.. of course, before accepting, they have the option
of passing it to a new task, provided they *make the cb block until
the accept is done* .. this is because, in libuv, you have to do the
uv_accept call in the span of that on_connect_cb callback that gets fired
when a new connection comes in. thems the breaks..
I wanted to just get rid of this API, because the general proposition of
users always running code on the libuv thread sounds like an invitation
for many future headaches. the API restriction to have to choose to
immediately accept a connection (and allow the user to block libuv as
needed) isn't too bad for power users who could conceive of circumstances
where they would drop an incoming TCP connection and know what they're
doing, in general.
but as a general API, I thought this was a bit cumbersome, so I ended up
devising..
2. an API that is initiated with a call to `net::tcp::new_listener()` ..
has a similar signature to `net::tcp::listen()`, except that is just
returns an object that sort of behaves like a `comm::port`. Users can
block on the `tcp_conn_port` to receive new connections, either in the
current task or in a new task, depending on which API route they take
(`net::tcp::conn_recv` or `net::tcp::conn_recv_spawn` respectively).. there
is also a `net::tcp::conn_peek` function that will do a peek on the
underlying port to see if there are pending connections.
The main difference, with this API, is that the low-level libuv glue is
going to *accept every connection attempt*, along with the overhead that
that brings. But, this is a much more hassle-free API for 95% of use
cases and will probably be the one that most users will want to reach for.
2012-05-17 15:27:08 -05:00
|
|
|
return current_kernel_malloc(size, "rust_uv_current_kernel_malloc");
|
2012-05-14 09:01:23 -05:00
|
|
|
}
|
|
|
|
|
2012-05-16 17:05:48 -05:00
|
|
|
extern "C" void
|
2012-05-14 09:01:23 -05:00
|
|
|
rust_uv_current_kernel_free(void* mem) {
|
std: splitting out tcp server API + tests
- we now have two interfaces for the TCP/IP server/listener workflow,
based on different user approaches surrounding how to deal with the
flow of accept a new tcp connection:
1. the "original" API closely mimics the low-level libuv API, in that we
have an on_connect_cb that the user provides *that is ran on the libuv
thread*. In this callback, the user can accept() a connection, turning it
into a tcp_socket.. of course, before accepting, they have the option
of passing it to a new task, provided they *make the cb block until
the accept is done* .. this is because, in libuv, you have to do the
uv_accept call in the span of that on_connect_cb callback that gets fired
when a new connection comes in. thems the breaks..
I wanted to just get rid of this API, because the general proposition of
users always running code on the libuv thread sounds like an invitation
for many future headaches. the API restriction to have to choose to
immediately accept a connection (and allow the user to block libuv as
needed) isn't too bad for power users who could conceive of circumstances
where they would drop an incoming TCP connection and know what they're
doing, in general.
but as a general API, I thought this was a bit cumbersome, so I ended up
devising..
2. an API that is initiated with a call to `net::tcp::new_listener()` ..
has a similar signature to `net::tcp::listen()`, except that is just
returns an object that sort of behaves like a `comm::port`. Users can
block on the `tcp_conn_port` to receive new connections, either in the
current task or in a new task, depending on which API route they take
(`net::tcp::conn_recv` or `net::tcp::conn_recv_spawn` respectively).. there
is also a `net::tcp::conn_peek` function that will do a peek on the
underlying port to see if there are pending connections.
The main difference, with this API, is that the low-level libuv glue is
going to *accept every connection attempt*, along with the overhead that
that brings. But, this is a much more hassle-free API for 95% of use
cases and will probably be the one that most users will want to reach for.
2012-05-17 15:27:08 -05:00
|
|
|
current_kernel_free(mem);
|
2012-05-14 09:01:23 -05:00
|
|
|
}
|
2012-06-20 09:01:43 -05:00
|
|
|
|
|
|
|
extern "C" int
|
2012-06-25 10:01:19 -05:00
|
|
|
rust_uv_getaddrinfo(uv_loop_t* loop, uv_getaddrinfo_t* handle,
|
2012-06-26 08:41:18 -05:00
|
|
|
uv_getaddrinfo_cb cb,
|
|
|
|
char* node, char* service,
|
|
|
|
addrinfo* hints) {
|
|
|
|
return uv_getaddrinfo(loop, handle, cb, node, service, hints);
|
2012-06-20 09:01:43 -05:00
|
|
|
}
|
2012-06-25 10:01:19 -05:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_freeaddrinfo(addrinfo* res) {
|
2012-06-26 08:41:18 -05:00
|
|
|
uv_freeaddrinfo(res);
|
2012-06-25 10:01:19 -05:00
|
|
|
}
|
2012-06-22 15:55:54 -05:00
|
|
|
extern "C" bool
|
|
|
|
rust_uv_is_ipv4_addrinfo(addrinfo* input) {
|
2012-06-26 08:41:18 -05:00
|
|
|
return input->ai_family == AF_INET;
|
2012-06-22 15:55:54 -05:00
|
|
|
}
|
2012-06-26 11:05:02 -05:00
|
|
|
extern "C" bool
|
|
|
|
rust_uv_is_ipv6_addrinfo(addrinfo* input) {
|
|
|
|
return input->ai_family == AF_INET6;
|
|
|
|
}
|
2012-06-22 15:55:54 -05:00
|
|
|
extern "C" addrinfo*
|
|
|
|
rust_uv_get_next_addrinfo(addrinfo* input) {
|
2012-06-26 08:41:18 -05:00
|
|
|
return input->ai_next;
|
2012-06-22 15:55:54 -05:00
|
|
|
}
|
|
|
|
extern "C" sockaddr_in*
|
|
|
|
rust_uv_addrinfo_as_sockaddr_in(addrinfo* input) {
|
2012-06-26 08:41:18 -05:00
|
|
|
return (sockaddr_in*)input->ai_addr;
|
2012-06-22 15:55:54 -05:00
|
|
|
}
|
|
|
|
extern "C" sockaddr_in6*
|
|
|
|
rust_uv_addrinfo_as_sockaddr_in6(addrinfo* input) {
|
2012-06-26 08:41:18 -05:00
|
|
|
return (sockaddr_in6*)input->ai_addr;
|
2012-06-22 15:55:54 -05:00
|
|
|
}
|