tls: re-enable .writev() on TLSWrap

[indutny]

Fix the parallel/test-tls-over-http-tunnel.js on Windows by
re-enabling the accidentally disabled .writev() method on TLSWrap.

It appears that there is some subtle issue with shutdown timing and it
manifests itself when the chunks are written in separate packets. This
leads to concurrent shutdown/destroy, which breaks the test.

cc @piscisaureus

It appears that removing writev in io.js prior to StreamBase does not introduce this problem, but this patch fixes the problem without touching the test. I propose landing it, and meanwhile I'll investigate more.

[indutny]

UPDATE: I was able to reproduce this problem on io.js prior to StreamBase changes after removing .cork()/.uncork() from _http_outgoing.js. So this is definitely unrelated.

[indutny]

cc @iojs/crypto @bnoordhuis seems to be an obvious change

[piscisaureus]

@indutny @indutny Interesting. What I found is that the number of callbacks that node expects (stream._wriableState.pendingcb) doesn't match what libuv thinks.

[indutny]

This is fine, because they are queued in TLSWrap

On Saturday, March 14, 2015, Bert Belder notifications@github.com wrote:

@indutny https://github.com/indutny @indutny
https://github.com/indutny Interesting. What I found is that the number
of callbacks that node expects (stream._wriableState.pendingcb) doesn't
match what libuv thinks.

—
Reply to this email directly or view it on GitHub
#1155 (comment).

[piscisaureus]

@indutny

This is fine, because they are queued in TLSWrap

It isn't, because this causes the socket to be destroyed before all writes are flushed (What happens is that pendingcb is 0 in node, but libuv still has two chunks of unwritten data).

[indutny]

Aah, well... This is a TLSWrap bug anyway, not StreamBase

On Saturday, March 14, 2015, Bert Belder notifications@github.com wrote:

@indutny https://github.com/indutny

This is fine, because they are queued in TLSWrap

It isn't, because this causes the socket to be destroyed before all writes
are flushed (What happens is that pendingcb is 0 in node, but libuv still
has two chunks of unwritten data).

—
Reply to this email directly or view it on GitHub
#1155 (comment).

[indutny]

On a second thought, it is very interesting case. This imbalance is happening because .shutdown() request is performing an uv_write() on TLS socket. Looking into improving this.

[indutny]

@piscisaureus LGTY?

[piscisaureus]

@indutny lgtm!

[indutny]

Landed in 4eb8810, thank you!