Home/ Questions/Q 7458935
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T13:50:02+00:00

I have written a perl XSUB wrapper for a very simple C API (for

  • 0

I have written a perl XSUB wrapper for a very simple C API (for which I dont have the source).

The C API consists of 4 functions. One of which returns a “handle” (just an int) and this value must be passed back to any of the other 3 functions to get the right internal “object” to call. One assumes the C API is keeping a list of these objects and dishing the right one out for the supplied handle.

When running in a standalone script, everything works great.

I’m now trying to get this API running under apache2 with mod_perl. Initially, everything works fine – I return the “handle” back to the client and the client then makes subsequent calls with the same handle value. But, after a (very short) period of inactivity, the C API decides that it has lost it’s lists of “objects” and starts over.

I assume this is because the underlying .so file is being unloaded.

So, my question:

Is there anything I can do to prevent apache/perl unloading this .SO? The only thing that seems to work is running apache in debug mode with -X.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I assume that the issue is that the SO has to do a lot of initialisation for the first request, and you want to avoid doing this repeatedly.

    It may help if you tweak the MPM settings.

    According to the MPM documentation, you can avoid the child processes being terminated and restarted, by setting the appropriate directives.

    In addition to the set of active child processes, there may be additional child processes which are terminating but where at least one server thread is still handling an existing client connection. Up to MaxClients terminating processes may be present, though the actual number can be expected to be much smaller. This behavior can be avoided by disabling the termination of individual child processes, which is achieved by the following:

    • set the value of MaxRequestsPerChild to zero

    • set the value of MaxSpareThreads to the same value as MaxClients

    This means that the two mechanisms for regulating the lifetime of child processes are turned off. First, processes terminate and restart automatically after MaxRequestsPerChild. Setting it to zero disables this. Second, if there are more than MaxSpareThreads sitting idle, child processes may be culled to conserve server resources. The second directive disables that process.

    • 0