[Info-vax] Reloading device drivers on x86-64 VMS

[Jan-Erik Soderholm]

Craig A. Berry skrev den 2015-03-09 03:23:
> On 3/8/15 8:38 PM, David Froble wrote:
>
>> If you want to install a new version of a sharable image, if it's
>> compatible with the old version, what does it matter how long before the
>> old version isn't used?  If it isn't compatible, I think you got more to
>> worry about than replacing a sharable image.
>
> I never said anything about loading a new version. The word was "unload"
> and in a subsequent post I referenced "a dlclose() or equivalent that
> actually frees up resources," which, despite the reference provided,
> seems not to have gotten the point across.
>
> Let me try again with an example. A modern web framework might have some
> dozens of modules or classes or extensions or plug-ins or assemblies or
> whatever the loadable pieces are called in your language of choice, and
> each might involve loading one or two or ten shareable images (or more,
> given the long dependency chains). A web server process might load up
> one set of these things to satisfy one request, but then need to load an
> entirely different set to satisfy the next request within the same
> process and main image activation, so you end up with all of the
> resources required by both sets allocated at the same time. Under some
> (but not all) circumstances, it might be desirable to be able to unload
> one set before loading another, basically undoing everything that was
> done by LIB$FIND_IMAGE_SYMBOL.
>

Probably better to make sure your needed routines are always loaded
to get the most performance out of your web server applications.
Just make sure you have whatever resources your environment and
users requires.

Is this a real problem today? Or just something "that other
system" has? And "I want that too!"? Maybe there are other
things to focus on than some "nice feature"?


> Which, as hb said, the VMS image activator cannot do. Which I knew,
> which is why I said it might be a nice feature to add, given that other
> OS's, such as Linux, already have it (the latter of which I didn't say
> previously, but seemed obvious in context).
>