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

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).

Merging into #32153.