PR_Poll function
Andy Gocke
the Unix socket API, NSPR seems to use an array of file descriptors,
instead of a set (fd_set). This presents me with a number of problems,
most notably how to keep a list of all current socket connections in
my program. Unlike a set, if I remove a socket from the array, it
would seem like I would have to move everything else in the array to
account for the missing slot. The way out of this would be for the
function to keep searching through the array until the number of
sockets in the array (second parameter) are all accounted for. This
would allow me to create an array of max socket numbers and then leave
empty slots in the array when I close one.
The simplest way to describe this is a basic free list (malloc) or
garbage collection system. My question is basically, how did you guys
plan on people using the NSPR API to deal with socket arrays? Did you
intend for the user to have to restructure the array constantly?
Andy
Nelson Bolyard
> I have a question about the operation of the PR_Poll function. Unlike
> the Unix socket API, NSPR seems to use an array of file descriptors,
> instead of a set (fd_set).
You seem to be aware of Unix's select() function which uses a bit array
where each bit corresponds to one of the low-numbered FDs. Perhaps you
are not aware that select() is only one of two (or more) different
methods offered by Unix to accomplish the purpose of waiting for activity
on an FD. Another Unix method is poll(). See
http://www.opengroup.org/onlinepubs/009695399/functions/poll.html
poll was introduced in SVR4 (IINM) and is now commonly offered in all Unix
and Unix-like OSes, and even in Windows. Unlike select(), poll() has the
property that it can easily handle large FD numbers. Unlike select(),
poll is easily used in systems where FD numbers are not small integers,
but are pointers or potentially large integers.
PR_Poll is NSPR's version of the poll() function. It was invented at a
time when several supported browser OSes had socket-like APIs that used
pointers instead of simple integers for FDs. A poll-like API is will
suited for that environment and a select-like API is not. NSPR's FDs
(formally known as PRFileDesc's) are pointers, and thus do not lend
themselves to use with select().
> This presents me with a number of problems, most notably how to keep a
> list of all current socket connections in my program.
That is, of course, an issue with or without PR_Poll, especially for
servers that may have very large numbers of sockets open simultaneously.
> Unlike a set, if I remove a socket from the array, it would seem like I
> would have to move everything else in the array to account for the
> missing slot.
The specification for PR_Poll https://developer.mozilla.org/en/PR_Poll
says that the fd member of the PRPollDesc structure "can be set to NULL
to indicate to PR_Poll that this PRFileDesc object should be ignored."
This is exactly analogous to Unix's poll() function, whose pollfd structure
also has a member named fd. According to the poll.html web page cited
above, "If the value of fd is less than 0, events shall be ignored, and
revents shall be set to 0 in that entry on return from poll()." So, both
poll() and PR_Poll() provide a way to "ignore" structures in the array.
> The way out of this would be for the function to keep searching through
> the array until the number of sockets in the array (second parameter) are
> all accounted for. This would allow me to create an array of max socket
> numbers and then leave empty slots in the array when I close one.
>
> The simplest way to describe this is a basic free list (malloc) or
> garbage collection system. My question is basically, how did you guys
> plan on people using the NSPR API to deal with socket arrays? Did you
> intend for the user to have to restructure the array constantly?
Now that you know how to mark array entries to be ignored, hopefully the
rest is self evident.