Reconsider providing hup as a readiness value for all *nix platforms.

[carllerche]

For epoll, HUP indicates that both the read and the write directions of a socket are closed. With kqueue, read and write directions are tracked separately. Each direction can have an optional EOF filter indicating that the direction is closed. There is no way to know that both directions are closed without tracking additional state.

However, for TCP, EOF for the write direction is equivalent to HUP. This does not apply to other types of evented handles.

The question is, how should this be normalized?

One option is to have hup be a platform specific readiness value. Another option would be to translate EPOLLHUP -> "write EOF" and document that for TCP, this indicates a HUP.

[carllerche]

This is a continuation of discussion starting here.

cc @Thomasdezeeuw @asomers

[Thomasdezeeuw]

I'm going to think about this a bit more over the weekend so it might take me a while to respond to this and #939. However I'm looking for some examples of how HUP is used currently, the only usage I could find is from Tokio.

If anyone uses HUP readiness could you share how you're using it, or point us to the code? I think that would help make a decision on how to handle this.

[carllerche]

@Thomasdezeeuw Ideally we can get #939 merged & released sooner than later as it is causing issues in production (cloudflare hit this recently).

[Thomasdezeeuw]

We could merge #939 and determine how to handle HUP cross-platform for 0.7.

[carllerche]

@Thomasdezeeuw I think that is the best strategy.

[Thomasdezeeuw]

#983 makes is_hup available on all platforms. Anything else that needs to be done?

[carllerche]

@Thomasdezeeuw The main question is if HUP will be triggered on only linux or on all *nix platforms. I believe we have to stick with Linux only here. I believe that all that is left to close this issue is verify that all HUP related code is deleted from kqueue.

[Thomasdezeeuw]

Shouldn't we document the different meaning for HUP on epoll/kqueue platforms and support both?

[carllerche]

@Thomasdezeeuw I do not know of a way to unify hup across linux & kqueue in a way that is more useful than just responding to read / write. In order for specialized events to be useful, they need stronger guarantees. This would allow the user to issuing syscalls when they know how the call will respond. AFAIK, there is no way to detect a full socket close on kqueue reliably w/o maintaining state:

I have some additional notes here: 17e2c7a

[Thomasdezeeuw]

Since HUP isn't supported by all platforms, i.e. Windows doesn't have it, I think it should be a bit of a second class citizen and documentation that it's very platform specific what HUP actually means. Or we should remove it completely, because as you said it's not really possible to mimic any platforms' behaviour.

[carllerche]

I would leave it but document that it is only fired on Linux.

[Thomasdezeeuw]

Current state on master is that Event::is_hup is provided on all unix platforms, but different when this occurs (i.e. it's platform specific we just pass on the information the OS provides) and this is clearly stated in the documentation. @carllerche anything left you want to here?

[carllerche]

@Thomasdezeeuw To be conservative, I would like to update the docs (for now) to say that linux is the only platform that is guaranteed to receive HUP events.

[carllerche]

as far as I know, we can only receive RDHUP events from kqueue...

[Thomasdezeeuw]

I was thinking about all the platform specific events; maybe we should just document which flags it checks for and point to the OS documentation.

[carllerche]

@Thomasdezeeuw sure, we can do that.

I think the only events we can guarantee cross platform will be readable and writeable.

[Thomasdezeeuw]

@carllerche yes all the others have a note about not being cross platform.

[Thomasdezeeuw]

I think #1037 solves this for the most part, so closing.