1213084 - NSPR PR_Poll() starvation

Status: NEW

(NSPR :: NSPR, defect)

Description

[Patrick McManus [:mcmanus]]

poll() is a level triggered API that gives the status of a set of FD's subject to the bits the caller expresses interest in.

However, PR_Poll() sometimes ignores silently some members of the set.

Specifically, when at least one member of the set successfully polls for an event at a layer above the IO_LAYER those members are immediately returned from PR_Poll() and all the other fd's are returned with 0 "out bits" set.

http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/pthreads/ptio.c?force=1#3828

this can lead to starvation and fairness problems.

consider two normal posix fds that have /dev/full open and are polled for read - each returns ready for read and the event loop serves them both.

now convert one of them to a PRFileDesc that always returns ready to read without having to use the OS fd. That has the same property as /dev/full, but if mixed with the /dev/full fd in one PR_Poll call the event loop will starve the OS driven one.

Firefox has run into this, mostly with SSL sockets (which can synthesize these events based on their state) starving out other kinds of sockets. Ironically it was the PollableEvent (based on a pipe) that got starved most obviously.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.