Skip to content

Conversation

@vii
Copy link
Contributor

@vii vii commented Dec 18, 2017

This is a refined version of the logic previously in #578

The rationale is that the consumer of sockets may wish to temporarily delay accepting for some reason (e.g. being out of file-descriptors). The kernel will then queue them up. The kernel queue is bounded and programs like NodeJS will actually try to quickly accept and then close (as the current behaviour before this PR).

However, it seems that libevent should allow the user to choose whether to accept and respond correctly if the listener is disabled.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.03%) to 80.537% when pulling d128382 on vii:master into 727bcea on libevent:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.03%) to 80.537% when pulling d128382 on vii:master into 727bcea on libevent:master.

@azat
Copy link
Member

azat commented Dec 18, 2017

Do you have a reproducer for such behavior?

azat referenced this pull request Jan 4, 2018
* listener-immediate-close:
  test/listener: cover immediate-close logic
  Immediately stop trying to accept more connections if listener disabled
@azat
Copy link
Member

azat commented Jan 4, 2018

So I wrote a regression tests (cb6995c) and applied you patch, thanks for catching this!

@azat azat closed this Jan 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants