Added argument to drain that provides the list of packets that are drained

[bytenik]

The kind of change this PR does introduce

• a bug fix
• a new feature
• an update to the documentation
• a code change that improves performance
• other

Current behavior

'drain' event occurs with no arguments

New behavior

'drain' event occurs with an argument containing the list of packets that were sent by the transport

Other information (e.g. related issues)

[darrachequesne]

Hmm, shouldn't you go a bit deeper and catch the drain event emitted by the HTTP response? In order to be sure that the packet has been written to the kernel buffer and can safely be released.

References:

• https://nodejs.org/api/http.html#responsewritechunk-encoding-callback
• https://nodejs.org/api/http.html#event-drain

Related: #5353

[bytenik]

Hmm, shouldn't you go a bit deeper and catch the drain event emitted by the HTTP response? In order to be sure that the packet has been written to the kernel buffer and can safely be released.

References:

• https://nodejs.org/api/http.html#responsewritechunk-encoding-callback
• https://nodejs.org/api/http.html#event-drain

Related: #5353

For Websockets, the ws library is handling that I think and it won't callback until its finished writing out. Do you see something different?

You are possibly right about long-polling though; I can defer our drain until the HTTP drain. I just pushed out that change. Though does long-polling even support buffers? I was under the impression it was base64-ing them.

I am not seeing a mechanism for uWebSockets to tell us when they have actually written out the buffer.