joyent / libuv Goto Github PK

because it makes the system much simpler on unix

note the use of the linux specific /proc/self/exe in test/runner-unix.c

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
%

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.

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:

• Return 0 on immediate completion, return -1 and set the last error to OIO_PENDING when the request pends.
• Return 0 on immediate completion, -1 on error, and -2 when the request pends.

remarks:

• Maybe It's hard to imagine a situation where a connect completes immediately. However, the windows ConnectEx call I'm making does not guarantee that the overlapped operation always returns WSA_IO_PENDING. Also it is not unexpected that connecting a pipe / fifo could be done synchronously.
• Implementations might choose to always report that a request is pending. For example, windows XP always reports completion asynchronously even if a request could be serviced immediately. (on later windowses this behavior can be specified with SetFileCompletionNotificationModes).

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.

at least in d91b501

Because the possible oio_req types differ between platforms.

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.

so that "make bench" outputs the results of pump100_server and pump1_server

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.

Note the use of the linux specific /proc/self/exe in test/runner-unix.c.

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.

• tree.h (from FreeBSD; 2-clause BSD license)
• ngx_queue.h (from nginx)
• libev

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.

dup

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.

this should be okay.

Create a simple bench mark server that writes 10K bytes to to a simple client.

The purpose of this issue is mainly to annoy Ryan.
Besides, we do need IPv6 support.

similar to this: https://github.com/joyent/libuv/blob/c41b7143c78b3215972799d3e77b4ae65394d065/test/test-loop-handles.c#L351-359

Should oio_req need to be initialized before each use? Currently in Linux this is necessary.

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.

982a620#L0R62

Need test

Once this is fixed, this line should be removed:

reproduce - remove line 62 from echo-server.c, run echo-server, connect send it 'Q', disconnect. It will not gracefully shutdown.

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.

that is, rename test-callback-stack.c

with timeout

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);

i.e. uv_write happens synchronously. currently on unix it seems we do not attempt to do the writes synchronously.

Need an API for it.

• Define error constants / strings / ... to unambiguously identify errors in a portable way.
• Retain the original error code somewhere so the platform's strerror / FormatMessage functionality can be used.
• Do it in a way that integrates nicely with node, and play nice with other parts of node that also report system errors.

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.

handles should not close automatically.

See also: #51

test-runner bug - it should fail if a helper fails.
@Gissues:{"order":75,"status":"backlog"}

Thinking about it makes my head hurt. But here's what:

Disgraceful disconnect

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.

Graceful disconnect

A socket can be closed after graceful shutdown when:

• A oio_read call has reported a zero byte read once
• The user has called oio_shutdown once, and
  oio_shutdown_cb has been called to indicate that the write queue was drained and a FIN has been sent.

Questions:

• Should we track which ends of the stream have been closed or should the user do that?
• Should oio_close be called automatically when a socket has been shut down at both ends?
• What if the user isn't reading the socket after shutting it down?

We need tests for oio_write after oio_shutdown and calling oio_shutdown multiple times. Neither should be allowed.

e.g on the uv_loop_cb

what else?

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.

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");

see https://github.com/joyent/liboio/commit/1a99dcc980d273d04a539b3baf30191a46e76cb6#L4R148