Re: Caching the result of require() across instances (multithreading / embedded).

[William Ahern <william@...>]

On Thu, Oct 04, 2012 at 03:48:10PM -0700, William Ahern wrote:
> On Thu, Oct 04, 2012 at 03:13:39PM -0400, John Craws wrote:
> <snip>
> > The problem occurs when one of the Lua files uses require(). With the
> > default loaders, there is no way (that I see) to share the result, so
> > each thread has to load the module. Consequently, the .so and .lua
> > files are reopened and reloaded every time. Is there a way to share
> > the result and have require() load once for all threads/instances (as
> > it does for multiple calls for the same module in the same
> > thread/instance)?
> 
<snip>
> But regarding the .so, it's always been my assumption that it won't actually
> get reloaded. AFAIU, the Linux dynamic linker should only load it from disk
> once, and then increment a reference counter. But I've never actually
> confirmed this.

FWIW, manual excerpts for dlopen(3):

(POSIX) Only a single copy of an object file is brought into the address
space, even if dlopen() is invoked multiple times in reference to the file,
and even if different pathnames are used to reference the file.

(Linux) If the same library is loaded again with dlopen(), the same file
handle is returned.

(OS X) A second call to dlopen() with the same path will return the same
handle, but the internal reference count for the handle will be incremented.

(OpenBSD) If the named shared object has already been loaded by a previous
call to dlopen() and not yet unloaded by dlclose(), a handle referring toe
the resident copy is returned.

(Solaris) If the object file is already part of the process, a handle is
also returned to the caller.