optimizing_applications_for_nspr.rst (2480B)
1 Optimizing applications for NSPR 2 ================================ 3 4 NetScape Portable Runtime (NSPR) tries to provide a consistent level of 5 service across the platforms it supports. This has proven to be quite 6 challenging, a challenge that was met to a large degree, but there is 7 always room for improvement. The casual client may not encounter a need 8 to know the details of the shortcomings to the level described here, but 9 if and when clients become more sophisticated, these issues will 10 certainly surface. 11 12 *This memo is by no way complete.* 13 14 Multiplatform 15 ------------- 16 17 - Do not call any blocking system call from a local thread. The only 18 exception to this rule is the <tt>select()</tt> and <tt>poll()</tt> 19 system calls on Unix, both of which NSPR has overridden to make sure 20 they are aware of the NSPR local threads. 21 - In the combined (MxN) model, which includes NT, IRIX (sprocs), and 22 pthreads-user, the primordial thread is always a local thread. 23 Therefore, if you call a blocking system call from the primordial 24 thread, it is going to block more than just the primordial thread and 25 the system may not function correctly. On NT, this problem is 26 especially obvious because the idle thread, which is in charge of 27 driving the asynch io completion port, is also blocked. Do not call 28 blocking system calls from the primordial thread. Create a global 29 thread and call the system call in that thread, and have the 30 primordial thread join that thread. 31 - NSPR uses timer signals to implement thread preemption for local 32 threads on some platforms. If all the software linked into the 33 application is not ported to the NSPR API, the application may fail 34 because of threads being preempted during critical sections. To 35 disable thread preemption call 36 <tt>PR_DisableClockInterrupts()</tt>during initialization. 37 - Interrupting threads (via <tt>PR_Interrupt()</tt>) on threads blocked 38 in I/O functions is implemented to various degrees on different 39 platforms. The UNIX based platforms all implement the function though 40 there may be up to a 5 second delay in processing the request. 41 - The mechanism used to implement <tt>PR_Interrupt()</tt> on the 42 *pthreads* versions of NSPR is flawed. No failure attributable to the 43 flaw has shown up in any tests or products - yet. The specific area 44 surrounding pthread's *continuation thread* has been both observed 45 and empirically proven faulty, and a correction identified.