针对 NSPR 优化应用程序

NetScape 可移植运行时 (NSPR) 试图在其支持的所有平台上提供一致的服务水平。事实证明，这是一项极具挑战性的任务，虽然在很大程度上已经克服了挑战，但始终有改进的空间。普通的用户可能不需要了解此处描述的不足之处，但随着用户变得更加精通，这些问题肯定会浮出水面。

这份备忘录绝非完整。

跨平台

• 不要从本地线程调用任何阻塞系统调用。此规则的唯一例外是在 Unix 上的 <tt>select()</tt> 和 <tt>poll()</tt> 系统调用，NSPR 已经覆盖了这两个调用以确保它们能够识别 NSPR 本地线程。

• 在组合 (MxN) 模型中（包括 NT、IRIX（sprocs）和 pthreads-user），原始线程始终是本地线程。因此，如果您从原始线程调用阻塞系统调用，它将阻塞的不仅仅是原始线程，系统也可能无法正常工作。在 NT 上，此问题尤其明显，因为负责驱动异步 IO 完成端口的空闲线程也被阻塞了。不要从原始线程调用阻塞系统调用。创建一个全局线程并在该线程中调用系统调用，并让原始线程加入该线程。

• NSPR 使用定时器信号在某些平台上实现本地线程的线程抢占。如果链接到应用程序的所有软件都没有移植到 NSPR API，则应用程序可能会由于在关键部分抢占线程而失败。要禁用线程抢占，请在初始化期间调用 <tt>PR_DisableClockInterrupts()</tt>。

• 在不同平台上，通过 <tt>PR_Interrupt()</tt> 中断在 I/O 函数中阻塞的线程的实现程度各不相同。基于 UNIX 的平台都实现了该函数，尽管处理请求可能延迟高达 5 秒。

• 在 NSPR 的 pthreads 版本中实现 <tt>PR_Interrupt()</tt> 的机制存在缺陷。在任何测试或产品中都没有发现任何可归因于该缺陷的故障 - 至少目前还没有。围绕 pthread 的 延续线程 的特定区域已被观察到并经实验证明存在故障，并且已经确定了修正方法。