libuv has moved to github.com/libuv/libuv
joyent / libuv Goto Github PK
View Code? Open in Web Editor NEWGo to
Home Page: https://github.com/libuv/libuv
Go to
Home Page: https://github.com/libuv/libuv
libuv has moved to github.com/libuv/libuv
Hello,
I was peeking into the project (heard from Rubinius guys at CodeConf) and was trying to build it using mingw-w64 GCC native on Windows.
http://mingw-w64.sourceforge.net/
It seems there are only two supported builds: Unix Makefile, which depends on libev and Windows solution files for Visual Studio.
Attempt to compile locally with it resulted in warnings and failure:
https://gist.github.com/925560
Considering not everybody will use Visual Studio, perhaps adding a Makefile.mingw
could help others to get started and help out?
Thank you.
dup
Because the possible oio_req types differ between platforms.
i.e. uv_write happens synchronously. currently on unix it seems we do not attempt to do the writes synchronously.
Thinking about it makes my head hurt. But here's what:
Currently, calling oio_close(handle) before the write queue is empty thrashes all data in the write queue. However the kernel will try to do a do a graceful disconnect anyway, so the client thinks he's received all data. This may be undesirable; an incomplete transfer should be recognizable as such by the other end. I think we need to set SO_LINGER with l_onoff=1 and l_linger=0 to achieve this.
A socket can be closed after graceful shutdown when:
Questions:
I wish upon a star that passing a backlog of -1 or 0 to uv_listen() would pick a sane platform default, like SOMAXCONN for *NIX systems.
I've been able to follow along find in Visual Studio Express 2010. Keeping the Visual Studio Projects at the Express level will make it easier to get new developers involved, since there is no cash requirement beyond the Windows license.
With the latest Visual Studio solution file, there is a new feature in use, "Solution Items", that is disabled on Visual Studio Express. The code appears to build, but the current branch is not building for other reasons.
I'm not sure what "Solution Items" are. I'm waiting to see if I can still build in Express. If they are not a big win for other developers, if you were just trying something out, I'm letting you know that it doesn't work in Express.
I'd like to keep this issue around, opened and closed, for general discussion of Visual Studio Express, if we continue to support it. If we don't, I'd like to at least commit an alternative express compatible build in a subdirectory. If that's not cool, I suppose I can create a project that sits in a sibling directory.
Need an API for it.
Our current strategy has been uv_ref
on each handle that is initialized. In libev watchers also increase the ref count when they are active. Should a handle increase the count by only one ever? Or is it allowed to increase it more? Since the unix backend is currently increasing the count more than once, Node does not exit naturally.
We need tests to verify we're acting the same on both platforms. Something like this:
TEST_IMPL(ref) {
uv_init(alloc_cb);
uv_idle_init(&idle_2_handle, NULL, NULL);
uv_run();
return 0;
}
TEST_IMPL(ref2) {
uv_init(alloc_cb);
uv_idle_init(&idle_2_handle, NULL, NULL);
uv_idle_start(&idle_2_handle, NULL);
uv_unref(&idle_2_handle);
uv_run();
return 0;
}
Note ref2 currently times out on unix.
see https://github.com/joyent/libuv/blob/9fc8a7f1670e6b6f223e48ebf390dd345a888007/uv-unix.c#L1238-1239
This probably implies passing argv
to uv_init()
. If this is the solution then #47 should be fixed first.
handles should not close automatically.
See also: #51
Note the use of the linux specific /proc/self/exe
in test/runner-unix.c
.
Should oio_req need to be initialized before each use? Currently in Linux this is necessary.
that is, rename test-callback-stack.c
Need test
Once this is fixed, this line should be removed:
Line 62 in 982a620
reproduce - remove line 62 from echo-server.c, run echo-server, connect send it 'Q', disconnect. It will not gracefully shutdown.
Once you figure out the fix for Win change
https://github.com/joyent/liboio/blob/master/test/runner-unix.c#L293
to be printf("\033[2K\r");
so that "make bench" outputs the results of pump100_server and pump1_server
this can be done by connecting - killing the helper (through some means...) and attempting to write to it. We should get OIO_EPIPE
from oio_write_cb
. Question: should the handle be closed automatically? I think so.
note the use of the linux specific /proc/self/exe
in test/runner-unix.c
This issue is spawned by:
https://github.com/joyent/libuv/blob/c8603a74621d7151c087afdafe23b79ee0a7832e/test/test-timer-again.c#L79-88
What should uv_is_active()
actually mean?
Suggestion: uv_is_active()
returns true until the handle's on_close callback is fired.
Purpose of this issue is to track 3rd-party code that has been integrated with liboio. Some day we'll need to add a proper license statement.
this should be okay.
Create a simple bench mark server that writes 10K bytes to to a simple client.
test-runner bug - it should fail if a helper fails.
@Gissues:{"order":75,"status":"backlog"}
oio_tcp_handle
oio_npipe_handle
oio_file_handle
oio_tty_handle
oio_timer_handle ?
it's annoying to have to specify a alloc callback for programs where you may never open a tcp socket.
at least in d91b501
e.g on the uv_loop_cb
what else?
I would like to change the API of uv_listen and uv_read to be a similar interface:
/* uv_accept() is used in conjunction with uv_listen() to accept incoming
* TCP connections. After receiving a uv_connection_cb call uv_accept() to
* accept the connection. Before calling uv_accept use uv_tcp_init() must be
* called on the client. Non-zero return value indicates an error.
*
* When the uv_connection_cb is called it is guaranteed that uv_accept()
* will complete successfully the first time. If you attempt to use it more
* than once, it may fail. It is suggested to only call uv_accept once per
* uv_connection_cb call.
*/
int uv_listen_start(uv_tcp_t* handle, int backlog, uv_connection_cb cb);
int uv_listen_stop(uv_tcp_t* handle);
int uv_accept(uv_tcp_t* server, uv_tcp_t* client);
/* Read data from an incoming stream. uv_read_start() allows the TCP handle
* to be notified of readablity via the read_cb. When the handle is readable
* uv_read() can be used to read the data
*
* Each time the uv_read_cb is called the user should call uv_read with a
* pointer to a uv_buf_t. For best results the user should provide a
* uv_buf_t with 64kb of space. The supplied buffer will be filled with TCP
* data.
*
* uv_read() will return zero when EOF is reached; -1 when an error occured.
*/
int uv_read_start(uv_tcp_t*, uv_read_cb read_cb);
int uv_read_stop(uv_tcp_t*);
ssize_t uv_read(uv_tcp_t*, uv_buf_t* buf);
Similar to the test executable (and using the test/test.h
) to run benchmarks in a cross platform fashion. First bench: max one-way TCP throughput between two sockets.
Want output to be simple and parsable for future CI system.
% test/benchmaks.exe
tcp-one-way-throughput 5782
tcp-ping-pong 12343
%
The purpose of this issue is mainly to annoy Ryan.
Besides, we do need IPv6 support.
UV_XXX constants seems to mirror POSIX constants. Why not use the actual POSIX definitions on unix and use a mapping on windows?
Or at least define UV_XXX to be XXX if XXX is defined.
because it makes the system much simpler on unix
We need tests for oio_write after oio_shutdown and calling oio_shutdown multiple times. Neither should be allowed.
with timeout
As discussed, oio_write, oio_read and oio_connect might complete synchronously. When that happens the request callback will not be made. How do we tell the user that this happened?
options:
remarks:
consider:
void after_read(oio_req *req, int read) {
free(req);
}
oio_handle_init(&handle, close_cb);
req = (oio_req*)malloc(sizeof(oio_req));
oio_req_init(req, &handle, after_read);
oio_read(req, &whatever_buf, 1);
oio_close(&handle);
// after_read is never called -> allocated req leaked.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.