Re: [libuv] on_error callback

[Ben Noordhuis]

On Fri, Nov 9, 2012 at 1:44 AM, Dhruv Matani <dhru...@gmail.com> wrote:
> Hello,
>
> I've just started using libuv, and was wondering if there exists an
> on_error() or global on_close() callback which is fired when a socket closes
> or is disconnected, etc...
> The only thing I could figure is to call uv_close() and unless that is
> called, it seems that the socket is NOT reclaimed/close(2)ed by the system,
> and counts toward the open FD count.
> I'm looking for something similar to the exfds FDSET when used with
> select(2).
>
> Regards,
> -Dhruv.

There is no global close or error hook in libuv. It's the
responsibility of the libuv user to always uv_close() a handle.

With TCP sockets, you check the status argument in your read_cb and
write_cb. If there is an error, you close the handle.

[Dhruv Matani]

So, in case that the user systematically closes the connection after sending in a valid stream of bytes (all of which have been read), I have seen the connection go into a state of being "there" (I mean in memory), with the FD open, but nothing happening - i.e. no more read events are being fired on it. How do you think this situation should be handled? Since the process quickly runs out of open FDs.

The client process in question is a node.js script and I am making http requests one after another, so I am guessing that node will close the connection if there are no pending http requests in the queue.

Here is the link to the code (just to make sure that I have understood how the http client behaves).

https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/tests/perf.js

This is the read callback, which is never called when the socket terminates: https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/src/httpserver.cpp#L101

And I am having to maintain an LRU list of open sockets here: https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/src/httpserver.cpp#L143

I am pretty sure that this is the wrong way to go about this problem, so am looking to see if you have a better way I should be doing this.

Regards,

-Dhruv.

[Ben Noordhuis]

On Fri, Nov 9, 2012 at 4:41 AM, Dhruv Matani <dhru...@gmail.com> wrote:
> So, in case that the user systematically closes the connection after sending
> in a valid stream of bytes (all of which have been read), I have seen the
> connection go into a state of being "there" (I mean in memory), with the FD
> open, but nothing happening - i.e. no more read events are being fired on
> it. How do you think this situation should be handled? Since the process
> quickly runs out of open FDs.
>
> The client process in question is a node.js script and I am making http
> requests one after another, so I am guessing that node will close the
> connection if there are no pending http requests in the queue.

Yes, that's correct.

> Here is the link to the code (just to make sure that I have understood how
> the http client behaves).
> https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/tests/perf.js
>
> This is the read callback, which is never called when the socket terminates:
> https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/src/httpserver.cpp#L101

Remember the "always close" rule. I'll reproduce your code here for
posterity's sake:

} else if (nread < 0) {
uv_err_t err = uv_last_error(uv_loop);
if (err.code != UV_EOF) {
UVERR(err, "read");
close_connection(client);
}
}

You close the connection when it's not an EOF. That's a bug, you
should *always* close it when nread == -1.

[Dhruv Matani]

Ah! Thanks for the quick clarification Ben!

I had picked up the code from Ryan's demo http server, hoping it would be bullet proof :-p