proposal: x/sys/unix: support for all fields of EpollEvent

[wI2L]

Similar to this discussion about kqueue, and related to this closed issue, it would be nice to add the missing fields of the C type epoll_event defined as the following to the equivalent unix.EpollEvent type in Go.

     typedef union epoll_data {
           void    *ptr;
           int      fd;
           uint32_t u32;
           uint64_t u64;
       } epoll_data_t;

       struct epoll_event {
           uint32_t     events;    /* Epoll events */
           epoll_data_t data;      /* User data variable */
       };

/cc @tklauser @bradfitz @ianlancetaylor

[bradfitz]

EpollEvent is currently https://godoc.org/golang.org/x/sys/unix#EpollEvent :

type EpollEvent struct {
    Events uint32
    Fd     int32
    Pad    int32
}

Go can't do unions, though. Even with unsafe, it's invalid to put a non-pointer in an unsafe.Pointer or a pointer in an integer. Both can lead to crashes.

To support both uint64 and unsafe.Pointer data values, we'd need two EpollEvent structs (e.g. EpollEventInt and EpollEventPtr) and then two EpollCtl variants.

But that doesn't help with EpollWait which can return a mix of events. (some with ints, some with pointers)

But perhaps we could just make the rule be that a given fd can only have one or the other and then you choose the epoll_wait variant that you used with epoll_ctl. shrug

[wI2L]

Thanks for the concise answer. Ian mentioned the lack of union in Go in the issue I cross-referenced, but it just clicked in my head after reading you and re-reading the epoll man page.

Following up what you said, could we instead choosing one of the two cases (the pointer one) as an opiniated solution instead ? One could always store the pointer to a int64 var if necessary, but the inverse isn't true.

As an example, my current use case for a pointer field would be to store a pointer to a net.Conn registered with the epoll instance (understand it's fd). This avoids having to manage a separate map that references each Conn by it's fd (which is the only useful "identifier" for an event pulled from epoll_wait).

[rsc]

Merging into #32153.