From 0f2ce403bbbf424fa180653e5e45354c3a354502 Mon Sep 17 00:00:00 2001 From: Jeff Hill Date: Mon, 30 Aug 2004 21:39:15 +0000 Subject: [PATCH] added warnings about calling CA from interrupt context, also more doc about vxWorks 5.4 netowrk stack pool --- src/ca/CAref.html | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/src/ca/CAref.html b/src/ca/CAref.html index cb7b7210f..3001f479f 100644 --- a/src/ca/CAref.html +++ b/src/ca/CAref.html @@ -132,6 +132,8 @@ height="31" width="88">

Common
  • Calling CA Functions from the vxWorks Shell Thread
    • +
  • Calling CA Functions from POSIX signal + handlers

    • Functionality Index 

    @@ -1648,6 +1650,13 @@ which vary between OS and even between different versions of the same OS.

    monitor subscriptions associated with stale connections which will rapidly increase the number of dedicated mbufs to the quota available for each circuit. +
  • When sites switch to the vxWorks 5.4 IP kernel they frequently run into + network pool exhaustion problems. This may be because the original + vxWorks IP kernel expanded the network pool as needed at runtime while + the new kernel's pool is statically configured at compile time, and does + not expand as needed at runtime. Also, at certain sites problems + related to vxWorks network driver pool exhaustion have also been reported + (this can also result in ENOBUF diagnostic messages).

    • Related Diagnostics

    @@ -1659,7 +1668,7 @@ which vary between OS and even between different versions of the same OS.

    mbuf based protocol control blocks have been consumed. The vxWorks commands (availability depending on vxWorks version) mbufShow, netStackSysPoolShow, and netStackDataPoolShow indicate how much space - remains in the mbuf pool. + remains in the network stack pool.
  • The RTEMS command "netstat [interest level]" displays network information including mbuf consumption statistics.
    • @@ -2178,6 +2187,13 @@ questionable practice for the following reasons.

    clean up on vxWorks. This is the same behavior as on all other OS. +

    Calling CA Functions from POSIX signal +handlers

    + +

    As you might expect, it isnt safe to call the CA client library from a +POSIX signal handler. Likewise, it isnt safe to call the CA client library +from interrupt context.

    +

    Function Call Reference

    ca_context_create()