-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/14/2014 08:17 PM, [email protected] wrote: >>> Besides removing the socket from the epoll/kqueue/etc. set, >>> uv_listen_stop() should probably also call listen(sock, 0), >>> otherwise new connections still end up in the accept queue. On >>> the other hand, I imagine that's sometimes the desired >>> behavior. > > The windows story is a bit more complicated because there is a iocp > queue of accepted connections. So listen_stop() could work but it > couldn't take effect immediately - the queue of incoming > connections would still be delivered to the completion port. We > could buffer them up for the time the user calls uv_listen() or > uv_listen_start(), or we could just dispatch them to the user and > the user would have to deal with the fact that listen_stop() is not > immediate. >
Yeah, I thought of that when I poked at the Windows side of things. I think it's acceptable to say that the already queued connections will still fire the callback. The user could check if the handle is active and not call uv_accept, for example. > I don't think listen(sock, 0) does what you guys think. The server > doesn't stop accepting connections - it just sets the backlog to > the default value. > Well, POSIX says that "The backlog argument provides a hint to the implementation which the implementation shall use to limit the number of outstanding connections in the socket's listen queue. " and "A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may be set to an implementation-defined minimum value." Which is fine, I guess. If the fd is not in the poller the kernel will queue connections and reject them once the queue fills up, we can set the backlog to 0 (or 1), with the hope that the queue is small enough so incoming connections are rejected asap. - -- Saúl Ibarra Corretgé bettercallsaghul.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTc7aQAAoJEEEOVVOum8BZdm0QAL1S0RKq39zQGqVu/0rYnFOp h7qm5SiqBuvpUojZKT4TBKi9myVC4eEOBWehA/mimn5iRX9Q5CjAb7YYPcVoMNrR /eHd+uqO0GwRvDX49yNXgI7CmRCiHWNAOj5BpVSjKowh3eYvWeZMu477txkJ8GKw 9K0Mv6WTwjdycotnN/Y01fna9D53yx16HKSPNrNQpcekA7ijDgH7h1JwI8atkhxG 4NHRuCu0k+vvVzO/t2T4Wsylxd3cxfqnPDcHthNjfiCgmCKP47LwPAlSKoapCx7n 3ISZYL+8yQq1SPp0kMqtVeNDgLu+u7xedHmqHpJGxVGGhxfCT8zY3CsCGnpY+n76 MnbS3vUkjJNWJ5AyetHD3Vj4ebFthgpyuUbpOWq1DSk31HUFaqbKQwZAyvrYeQBl 7rDHId9nEztsH2NUn0olabsfBvNMRy4pzwcCp973k5uKruSv5mrp9iiloZv81+49 25ddjc4Zu4NFbdEBq53QiKTvC6Bavx8CkFUDRqO7wBCFzrtXVlsyhN9pfOuiqz3D ej4+RKTPWoktCwhZZ5Hm7kNowV9K6L93neuArESWji9i1c2xIuC0YvQnIUrGs6Am eagAJauEUsTlhIj+OFBk93JY2/+diauZwiG0OQvh66TIug2ExUB5C3PMmUAxVG3+ RTLEz0RJqaC6VmrwJGrX =rOUU -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
