On Fri, Nov 9, 2012 at 1:44 AM, Dhruv Matani <dhruvb...@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.

On Thursday, November 8, 2012 8:02:06 PM UTC-5, Ben Noordhuis wrote:
> On Fri, Nov 9, 2012 at 1:44 AM, Dhruv Matani <dhru...@gmail.com<javascript:>>
> 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.

On Fri, Nov 9, 2012 at 4:41 AM, Dhruv Matani <dhruvb...@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.

> 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...

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

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

> 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.

On Thursday, November 8, 2012 11:04:24 PM UTC-5, Ben Noordhuis wrote:
> On Fri, Nov 9, 2012 at 4:41 AM, Dhruv Matani <dhru...@gmail.com<javascript:>>
> 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...

> > This is the read callback, which is never called when the socket
> terminates:

> https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/src/h...

> 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.

> > And I am having to maintain an LRU list of open sockets here:

> https://github.com/duckduckgo/cpp-libface/blob/libuv-httpserver/src/h...

> > 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.