Stanley Hopcroft <[EMAIL PROTECTED]> writes:
>Dear Ladies and Gentlemen,
>
>For many years, the network monitor named Netsaint and latterly Nagios
>has happily embedded Perl and reaped the same sorts of benefits from
>Perl 'service checks' as Apache does with Perl CGIs from mod_perl
>(although the embedding support in Nag is orders of magnitude less
>sophisticated than mod_perl 1.x).
>
>The latest Nagios branch, 2.x, is a POSIX threaded application (lots of
>pthread_foo() calls).
>
>Nagios 2.x when built with an embedded non threaded Perl (5.005_03 -
>using the ccopts and ldopts from ExtUtils::Embed) cores with a SEGV from
>libc at exit(), but does not __without__ an embedded Perl interpreter.
Things _might_ be better if you:
A. Used a more modern perl - I have nothing specific in mind but
perl5.8 has had a lot of cleanup to threaded things. Cleaner
use of possibly-threaded APIs may help even a non-threaded perl.
B. Configure-d the perl to link against same libraries / includes
that will be used in the embedded case.
This is so that when Configure probes for behaviour of something
that is in -lpthread (or wherever) it finds behaviour of
one it will use not the one in -lc.
>
>Is attempting to build a threaded app with an embedded non threaded Perl
>even sensible ?
Providing non-threaded perl is build to be re-entrant (-DMULTIPLCITY)
and the threaded app takes care to ensure only one thread is in it at
a time (mutex lock round calls into perl) it might work -
but the short answer is no.
Why not embed a threaded (perl5.6+ style) perl?
Note then even here you either need the mutex locks or every thread
needs to create its own perl instance.
>If so, how does one do so on *BSD platforms (FreeBSD 4.x in partic) that
>do not seem to have thread implementation that are as good as other
>platforms ?
>
>Thank you.
>
>Yours sincerely.
>
> --
>Stanley Hopcroft
>
>Network specialist, IT Infrastructure
>IP Australia
>Ph: (02) 6283 3189 Fax: (02) 6281 1353
>PO Box 200 Woden ACT 2606
>http//:www.ipaustralia.gov.au
