1343699 - Consider using poll() instead of libevent

Status: NEW

(Core :: IPC, enhancement, P3)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I think this would be a reasonable way to reduce our attach surface. We only use libevent on Linux and Mac, and only then on non-UI threads. There aren't that many channels that we need to watch, so I suspect poll() is fast enough for our needs. Getting rid of libevent would get rid of a lot of crufty old C code.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

CC jesup who might bring in libevent through WebRTC deps.

Comment 2

[Jan Beich]

Mortar (bug 1345330) is another libevent consumer in the tree.

Comment 3

[Nils Ohlmeier [:drno]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)
> CC jesup who might bring in libevent through WebRTC deps.

I'm pretty sure that none of the WebRTC parts requires libevent.

It might be beneficial from WebRTC perspective to switch something else then select() for our actual network IO in Necko (because WebRTC creates a lot more sockets), but I think that is a different story.

Comment 4

[Nils Ohlmeier [:drno]]

(In reply to Nils Ohlmeier [:drno] from comment #3)
> It might be beneficial from WebRTC perspective to switch something else then
> select() for our actual network IO in Necko (because WebRTC creates a lot
> more sockets), but I think that is a different story.

Turns out that Necko appears to use poll() on the majority of the OS's already. So disregard that comment.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Another thing we could maybe do here is use the Rust crate "mio", which we're already building, and which is vaguely similar to libevent as I understand it.  It might not be more work than writing glue for poll(), and that way we could delete the imported libevent and still continue using scalable APIs like epoll and kqueue.  Necko might also be able to use it, but it would need extra glue to deal with NSPR.