varnishd: always shutdown both ends to a backend

[asadsa92]

No description provided.

[nigoroll]

Looks like a good catch to me, but should we not handle the pfd as in vcp_handle() here?

• call the close method, because otherwise we leak file descriptors
• free the pfd, because otherwise we leak memory

[dridi]

Looks like a good catch to me, but should we not handle the pfd as in vcp_handle() here?

The loop below is waiting for waiters to notice the shutdown and call vcp_handle().

[dridi]

Actually on this topic, this sleeping loop is something we should move as a CLI hook, waiting asynchronously for connection pools to be freed before deleting them for good.

[nigoroll]

The loop below is waiting for waiters to notice the shutdown and call vcp_handle().

Ah, this makes sense, thank you.

FWIW, @asadsa92 please add such explanations to the issue description or commit message. Leaving it to reviewers to figure out for themselves is no good use of their time.

this sleeping loop is something we should move as a CLI hook, waiting asynchronously for connection pools to be freed

yes.

[dridi]

this sleeping loop is something we should move as a CLI hook, waiting asynchronously for connection pools to be freed

yes.

I will follow up on that, I know someone who can work on this.

[asadsa92]

FWIW, @asadsa92 please add such explanations to the issue description or commit message. Leaving it to reviewers to figure out for themselves is no good use of their time.

Sorry about that.
This is kind of the gist of the issue, once the read side of the socket is shutdown the waiter issues a notification which calls the vcp_handle to clean up. Not closing the read side result in no notification from the waiter.

[dridi]

bugwash: merge