2012-12-10 15:44:02 -08: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 17:14:28 -07:00
|
|
|
#ifdef __WIN32__
|
|
|
|
// For alloca
|
|
|
|
#include <malloc.h>
|
|
|
|
#endif
|
2012-04-02 22:18:01 -05:00
|
|
|
|
2013-08-21 15:13:01 -07:00
|
|
|
#ifndef __WIN32__
|
|
|
|
// for signal
|
|
|
|
#include <signal.h>
|
|
|
|
#endif
|
|
|
|
|
2013-07-03 23:33:59 -04:00
|
|
|
#include "uv.h"
|
|
|
|
|
2012-04-02 22:18:01 -05:00
|
|
|
#include "rust_globals.h"
|
2011-11-30 23:26:23 -08:00
|
|
|
|
2012-02-22 14:00:34 -08:00
|
|
|
extern "C" void*
|
2011-11-30 23:26:23 -08:00
|
|
|
rust_uv_loop_new() {
|
2013-08-21 15:13:01 -07:00
|
|
|
// XXX libuv doesn't always ignore SIGPIPE even though we don't need it.
|
|
|
|
#ifndef __WIN32__
|
|
|
|
signal(SIGPIPE, SIG_IGN);
|
2013-08-22 16:33:59 -07:00
|
|
|
#endif
|
2012-02-22 14:00:34 -08:00
|
|
|
return (void*)uv_loop_new();
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_loop_set_data(uv_loop_t* loop, void* data) {
|
|
|
|
loop->data = data;
|
2011-11-30 23:26:23 -08:00
|
|
|
}
|
|
|
|
|
2012-03-29 15:11:21 -07:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_connect(uv_connect_t* connect_ptr,
|
2012-04-01 21:43:39 -07: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 15:11:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_bind(uv_tcp_t* tcp_server, sockaddr_in* addr_ptr) {
|
2012-04-01 21:43:39 -07:00
|
|
|
// FIXME ref #2064
|
|
|
|
sockaddr_in addr = *addr_ptr;
|
|
|
|
return uv_tcp_bind(tcp_server, addr);
|
2012-03-29 15:11:21 -07:00
|
|
|
}
|
2012-06-26 12:47:44 -07: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 15:11:21 -07:00
|
|
|
|
2012-10-19 19:28:58 -04:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_getpeername
|
2013-07-25 02:33:43 -04:00
|
|
|
(uv_tcp_t* handle, sockaddr_storage* name) {
|
|
|
|
// sockaddr_storage is big enough to hold either
|
|
|
|
// sockaddr_in or sockaddr_in6
|
2012-10-19 19:28:58 -04:00
|
|
|
int namelen = sizeof(sockaddr_in);
|
|
|
|
return uv_tcp_getpeername(handle, (sockaddr*)name, &namelen);
|
|
|
|
}
|
|
|
|
|
2013-07-02 16:40:57 -07:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_tcp_getsockname
|
2013-07-25 02:33:43 -04:00
|
|
|
(uv_tcp_t* handle, sockaddr_storage* name) {
|
|
|
|
// sockaddr_storage is big enough to hold either
|
|
|
|
// sockaddr_in or sockaddr_in6
|
|
|
|
int namelen = sizeof(sockaddr_storage);
|
2013-07-02 16:40:57 -07:00
|
|
|
return uv_tcp_getsockname(handle, (sockaddr*)name, &namelen);
|
|
|
|
}
|
|
|
|
|
2013-06-13 12:51:32 -07:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_udp_bind(uv_udp_t* server, sockaddr_in* addr_ptr, unsigned flags) {
|
|
|
|
return uv_udp_bind(server, *addr_ptr, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_udp_bind6(uv_udp_t* server, sockaddr_in6* addr_ptr, unsigned flags) {
|
|
|
|
return uv_udp_bind6(server, *addr_ptr, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
2013-06-25 14:40:36 -07:00
|
|
|
rust_uv_udp_send(uv_udp_send_t* req, uv_udp_t* handle, uv_buf_t* buf_in,
|
2013-06-13 12:51:32 -07:00
|
|
|
int buf_cnt, sockaddr_in* addr_ptr, uv_udp_send_cb cb) {
|
|
|
|
return uv_udp_send(req, handle, buf_in, buf_cnt, *addr_ptr, cb);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
2013-06-25 14:40:36 -07:00
|
|
|
rust_uv_udp_send6(uv_udp_send_t* req, uv_udp_t* handle, uv_buf_t* buf_in,
|
2013-06-13 12:51:32 -07:00
|
|
|
int buf_cnt, sockaddr_in6* addr_ptr, uv_udp_send_cb cb) {
|
|
|
|
return uv_udp_send6(req, handle, buf_in, buf_cnt, *addr_ptr, cb);
|
|
|
|
}
|
|
|
|
|
2013-06-14 11:39:46 -07:00
|
|
|
extern "C" uv_udp_t*
|
|
|
|
rust_uv_get_udp_handle_from_send_req(uv_udp_send_t* send_req) {
|
|
|
|
return send_req->handle;
|
|
|
|
}
|
|
|
|
|
2013-07-02 16:40:57 -07:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_udp_getsockname
|
2013-07-25 02:33:43 -04:00
|
|
|
(uv_udp_t* handle, sockaddr_storage* name) {
|
|
|
|
// sockaddr_storage is big enough to hold either
|
|
|
|
// sockaddr_in or sockaddr_in6
|
|
|
|
int namelen = sizeof(sockaddr_storage);
|
2013-07-02 16:40:57 -07:00
|
|
|
return uv_udp_getsockname(handle, (sockaddr*)name, &namelen);
|
|
|
|
}
|
|
|
|
|
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 21:42:07 -07:00
|
|
|
extern "C" uv_stream_t*
|
2012-03-26 11:09:57 -07:00
|
|
|
rust_uv_get_stream_handle_from_connect_req(uv_connect_t* connect) {
|
2012-04-01 21:43:39 -07: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 21:42:07 -07:00
|
|
|
}
|
2012-03-26 11:09:57 -07:00
|
|
|
extern "C" uv_stream_t*
|
|
|
|
rust_uv_get_stream_handle_from_write_req(uv_write_t* write_req) {
|
2012-04-01 21:43:39 -07:00
|
|
|
return write_req->handle;
|
2012-03-26 11:09:57 -07: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 21:42:07 -07:00
|
|
|
|
|
|
|
extern "C" uv_loop_t*
|
|
|
|
rust_uv_get_loop_for_uv_handle(uv_handle_t* handle) {
|
2012-04-01 21:43:39 -07: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 21:42:07 -07:00
|
|
|
}
|
|
|
|
|
2012-04-12 23:09:43 -07: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 21:42:07 -07:00
|
|
|
extern "C" void*
|
|
|
|
rust_uv_get_data_for_uv_handle(uv_handle_t* handle) {
|
2012-04-01 21:43:39 -07: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 21:42:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
2013-04-18 15:53:29 -07:00
|
|
|
rust_uv_set_data_for_uv_handle(uv_handle_t* handle, void* data) {
|
2012-04-01 21:43:39 -07:00
|
|
|
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 21:42:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void*
|
|
|
|
rust_uv_get_data_for_req(uv_req_t* req) {
|
2012-04-01 21:43:39 -07: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 21:42:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_set_data_for_req(uv_req_t* req, void* data) {
|
2012-04-01 21:43:39 -07: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 21:42:07 -07:00
|
|
|
}
|
|
|
|
|
2012-03-22 21:15:39 -07: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 21:42:07 -07:00
|
|
|
rust_uv_ip4_addr(const char* ip, int port) {
|
2012-04-01 21:43:39 -07:00
|
|
|
struct sockaddr_in addr = uv_ip4_addr(ip, port);
|
|
|
|
return addr;
|
2012-03-22 21:15:39 -07:00
|
|
|
}
|
2012-06-12 08:38:22 -07:00
|
|
|
extern "C" struct sockaddr_in6
|
|
|
|
rust_uv_ip6_addr(const char* ip, int port) {
|
2012-06-27 15:28:03 -07:00
|
|
|
return uv_ip6_addr(ip, port);
|
2012-06-12 08:38:22 -07:00
|
|
|
}
|
2013-03-12 20:04:25 -07:00
|
|
|
|
|
|
|
extern "C" struct sockaddr_in*
|
|
|
|
rust_uv_ip4_addrp(const char* ip, int port) {
|
|
|
|
struct sockaddr_in addr = uv_ip4_addr(ip, port);
|
|
|
|
struct sockaddr_in *addrp = (sockaddr_in*)malloc(sizeof(struct sockaddr_in));
|
|
|
|
assert(addrp);
|
|
|
|
memcpy(addrp, &addr, sizeof(struct sockaddr_in));
|
|
|
|
return addrp;
|
|
|
|
}
|
|
|
|
extern "C" struct sockaddr_in6*
|
|
|
|
rust_uv_ip6_addrp(const char* ip, int port) {
|
|
|
|
struct sockaddr_in6 addr = uv_ip6_addr(ip, port);
|
|
|
|
struct sockaddr_in6 *addrp = (sockaddr_in6*)malloc(sizeof(struct sockaddr_in6));
|
|
|
|
assert(addrp);
|
|
|
|
memcpy(addrp, &addr, sizeof(struct sockaddr_in6));
|
|
|
|
return addrp;
|
|
|
|
}
|
|
|
|
|
2013-07-25 02:33:43 -04:00
|
|
|
extern "C" struct sockaddr_storage *
|
|
|
|
rust_uv_malloc_sockaddr_storage() {
|
|
|
|
struct sockaddr_storage *ss = (sockaddr_storage *)malloc(sizeof(struct sockaddr_storage));
|
|
|
|
return ss;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_free_sockaddr_storage(struct sockaddr_storage *ss) {
|
|
|
|
free(ss);
|
|
|
|
}
|
|
|
|
|
2013-03-12 20:04:25 -07:00
|
|
|
extern "C" void
|
|
|
|
rust_uv_free_ip4_addr(sockaddr_in *addrp) {
|
|
|
|
free(addrp);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_uv_free_ip6_addr(sockaddr_in6 *addrp) {
|
|
|
|
free(addrp);
|
|
|
|
}
|
2012-10-19 19:28:58 -04: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-11 22:14:16 -07:00
|
|
|
|
2013-07-02 16:40:57 -07:00
|
|
|
extern "C" int
|
|
|
|
rust_uv_is_ipv4_sockaddr(sockaddr* addr) {
|
|
|
|
return addr->sa_family == AF_INET;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_is_ipv6_sockaddr(sockaddr* addr) {
|
|
|
|
return addr->sa_family == AF_INET6;
|
|
|
|
}
|
|
|
|
|
2012-06-22 13:55:54 -07:00
|
|
|
extern "C" bool
|
|
|
|
rust_uv_is_ipv4_addrinfo(addrinfo* input) {
|
2012-06-26 06:41:18 -07:00
|
|
|
return input->ai_family == AF_INET;
|
2012-06-22 13:55:54 -07:00
|
|
|
}
|
2013-07-02 16:40:57 -07:00
|
|
|
|
2012-06-26 09:05:02 -07:00
|
|
|
extern "C" bool
|
|
|
|
rust_uv_is_ipv6_addrinfo(addrinfo* input) {
|
|
|
|
return input->ai_family == AF_INET6;
|
|
|
|
}
|
2012-06-22 13:55:54 -07:00
|
|
|
extern "C" addrinfo*
|
|
|
|
rust_uv_get_next_addrinfo(addrinfo* input) {
|
2012-06-26 06:41:18 -07:00
|
|
|
return input->ai_next;
|
2012-06-22 13:55:54 -07:00
|
|
|
}
|
|
|
|
extern "C" sockaddr_in*
|
|
|
|
rust_uv_addrinfo_as_sockaddr_in(addrinfo* input) {
|
2012-06-26 06:41:18 -07:00
|
|
|
return (sockaddr_in*)input->ai_addr;
|
2012-06-22 13:55:54 -07:00
|
|
|
}
|
|
|
|
extern "C" sockaddr_in6*
|
|
|
|
rust_uv_addrinfo_as_sockaddr_in6(addrinfo* input) {
|
2012-06-26 06:41:18 -07:00
|
|
|
return (sockaddr_in6*)input->ai_addr;
|
2012-06-22 13:55:54 -07:00
|
|
|
}
|
2013-02-03 18:15:43 -08:00
|
|
|
|
2013-03-12 20:04:25 -07:00
|
|
|
extern "C" uintptr_t
|
|
|
|
rust_uv_handle_type_max() {
|
|
|
|
return UV_HANDLE_TYPE_MAX;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" uintptr_t
|
|
|
|
rust_uv_req_type_max() {
|
|
|
|
return UV_REQ_TYPE_MAX;
|
|
|
|
}
|
2013-08-15 23:54:54 -07:00
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_get_result_from_fs_req(uv_fs_t* req) {
|
|
|
|
return req->result;
|
|
|
|
}
|
2013-10-29 23:31:07 -07:00
|
|
|
extern "C" const char*
|
|
|
|
rust_uv_get_path_from_fs_req(uv_fs_t* req) {
|
|
|
|
return req->path;
|
|
|
|
}
|
2013-09-16 13:25:10 -07:00
|
|
|
extern "C" void*
|
|
|
|
rust_uv_get_ptr_from_fs_req(uv_fs_t* req) {
|
|
|
|
return req->ptr;
|
|
|
|
}
|
2013-08-15 23:54:54 -07:00
|
|
|
extern "C" uv_loop_t*
|
|
|
|
rust_uv_get_loop_from_fs_req(uv_fs_t* req) {
|
|
|
|
return req->loop;
|
|
|
|
}
|
2013-09-04 18:51:14 -07:00
|
|
|
|
|
|
|
extern "C" uv_loop_t*
|
|
|
|
rust_uv_get_loop_from_getaddrinfo_req(uv_getaddrinfo_t* req) {
|
|
|
|
return req->loop;
|
|
|
|
}
|
2013-08-26 07:24:10 -07:00
|
|
|
|
|
|
|
extern "C" void
|
2013-09-14 09:33:53 -07:00
|
|
|
rust_uv_populate_uv_stat(uv_fs_t* req_in, uv_stat_t* stat_out) {
|
|
|
|
stat_out->st_dev = req_in->statbuf.st_dev;
|
|
|
|
stat_out->st_mode = req_in->statbuf.st_mode;
|
|
|
|
stat_out->st_nlink = req_in->statbuf.st_nlink;
|
|
|
|
stat_out->st_uid = req_in->statbuf.st_uid;
|
|
|
|
stat_out->st_gid = req_in->statbuf.st_gid;
|
|
|
|
stat_out->st_rdev = req_in->statbuf.st_rdev;
|
|
|
|
stat_out->st_ino = req_in->statbuf.st_ino;
|
|
|
|
stat_out->st_size = req_in->statbuf.st_size;
|
|
|
|
stat_out->st_blksize = req_in->statbuf.st_blksize;
|
|
|
|
stat_out->st_blocks = req_in->statbuf.st_blocks;
|
|
|
|
stat_out->st_flags = req_in->statbuf.st_flags;
|
|
|
|
stat_out->st_gen = req_in->statbuf.st_gen;
|
|
|
|
stat_out->st_atim.tv_sec = req_in->statbuf.st_atim.tv_sec;
|
|
|
|
stat_out->st_atim.tv_nsec = req_in->statbuf.st_atim.tv_nsec;
|
|
|
|
stat_out->st_mtim.tv_sec = req_in->statbuf.st_mtim.tv_sec;
|
|
|
|
stat_out->st_mtim.tv_nsec = req_in->statbuf.st_mtim.tv_nsec;
|
|
|
|
stat_out->st_ctim.tv_sec = req_in->statbuf.st_ctim.tv_sec;
|
|
|
|
stat_out->st_ctim.tv_nsec = req_in->statbuf.st_ctim.tv_nsec;
|
|
|
|
stat_out->st_birthtim.tv_sec = req_in->statbuf.st_birthtim.tv_sec;
|
|
|
|
stat_out->st_birthtim.tv_nsec = req_in->statbuf.st_birthtim.tv_nsec;
|
2013-08-26 07:24:10 -07:00
|
|
|
}
|
|
|
|
|
2013-09-16 15:28:56 -07:00
|
|
|
extern "C" void
|
|
|
|
rust_set_stdio_container_flags(uv_stdio_container_t *c, int flags) {
|
|
|
|
c->flags = (uv_stdio_flags) flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_set_stdio_container_fd(uv_stdio_container_t *c, int fd) {
|
|
|
|
c->data.fd = fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
rust_set_stdio_container_stream(uv_stdio_container_t *c, uv_stream_t *stream) {
|
|
|
|
c->data.stream = stream;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" int
|
|
|
|
rust_uv_process_pid(uv_process_t* p) {
|
|
|
|
return p->pid;
|
|
|
|
}
|