Closed Bug 38599 Opened 24 years ago Closed 24 years ago

Better implementation of PR_Poll on Unix

Categories

(NSPR :: NSPR, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtc, Assigned: wtc)

Details

On Unix, PR_Poll allocates a pollfd structure array from
the heap and frees it in each invocation.  This is
inefficient.  Two optimizations are possible.

1. Allocate a pollfd structure array on the stack and use
   it if the number of poll descriptors is <= the size of this
   array.  This optimization is already implemented but we
   only allocate an array of size 4, which is too small for
   server applications.  I suggest that we increase the size
   of this array to 128.  Since a pollfd structure is 8 bytes
   (one int + two shorts), an array of 128 pollfd structures
   is 1K bytes, which seems to be an appropriate maximum.
   (NSPR's default thread stack size is 64K bytes.)

2. Make the malloc'ed pollfd structure array a thread-private
   data.  We can allocate this array in 128-element (1K-byte)
   increments so that we don't call realloc() too often.
Target Milestone: --- → 4.1
Status: NEW → ASSIGNED
I checked in the following changes on the tip.
1. I increased the size of the stack pollfd structure array from
   4 elements to 64 elements (512 bytes).  I did not increase it
   to 128 elements (1024 bytes) because I'm concerned about stack
   overflow of threads with smaller than default stack size.
2. I made the malloc'ed pollfd structure array a thread private
   data.  I allocate the exact required size, as opposed to
   some chunk size.

/cvsroot/mozilla/nsprpub/pr/include/private/primpl.h, revision 3.44
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptio.c, revision 3.57
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptthread.c, revision 3.35
I removed an extra semicolon in ptthread.c.  Doh!
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptthread.c, revision 3.36

Added a new test prpollml.c.  This test exercises the code that
allocates and frees the thread-private pollfd structure array.
I ran this test under Purify on Solaris 2.6 and verified that
there is no memory leak.

Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.