On Tue, Mar 27, 2001 at 02:38:34PM -0800, Perrin Harkins wrote:

> On Tue, 27 Mar 2001, DeWitt Clinton wrote:
>
> > I imagine that nearly most Perl libraries are not thread safe, of
> > course.  But code that will be used in mod_perl environments needs
> > to be, right?
> 
> You can read all about it here:
> http://www.apache.org/~dougm/modperl_2.0.html
> 
> The gist is that you probably don't need to change any Perl code, but some
> XS modules on CPAN may have to change.

Great pointer, Perrin.  So, according to Doug:

  The Perl ``ithreads'' implementation ensures that Perl code is
  thread safe, at least with respect to the Apache threads in which it
  is running. However, it does not ensure that extensions which call
  into third-party C/C++ libraries are thread safe. In the case of
  non-threadsafe extensions, if it is not possible to fix those
  routines, care will need to be taken to serialize calls into such
  functions (either at the xs or Perl level).

  Another issue is that ``global'' variables are only global to the
  interpreter in which they are created. Some research has been done
  on the concept of solar variables which are global across all
  interpreter instances. It has not been decided if this feature would
  best fit built into the Perl core or as an extension, but fear not,
  the feature will be provided in one form or another.

Now, this implies that a module, such as the Cache::MemoryCache, which
currently shares data for a particular process by creating a global
hash, would only share data for one instance of the Perl interpreter
associated with that thread.  If I wanted to extend the cache to share
data between multiple threads, I would create what Doug calls a
"solar" variable to hold that hash, correct?  Neat!

Cheers,

-DeWitt

Reply via email to