A few comments on some things that have come up while implimenting
embedded perl support:
First off, only the development branch of Perl supports the
concurrency features needed, and it must be compiled with USE_THREADS
and IMPLICIT_CONTEXT.
To use an older perl requires that it still be compiled with
MULTIPLICITY, _and_ be mutex-protected (making all perl-using threads
wait in line). I think everyone agrees that this is a Bad Thing.
Anyhow, I'm anticipating that not everyone will want to recompile the
latest perl for the sake of working on Asterisk; I can add support for
using an old perl (so the folks who are just playing with their one
OSS device can be fine), if anyone deems that appropriate. Also up for
discussion are some makefile changes -- embedding perl requires a
few. Should these changes be made for everyone, or just when a
perl-enabled Asterisk is being built?
Next, regarding some speed-related issues -- I'm doing something
rather similar to mod_perl here (though quite a bit simpler) and
reusing compiled code between calls. This means that any perl that's
not clean for this (requires that some global variable be set to an
initial value each startup but doesn't reset it after a run) will need
modifying. If someone needs it to be so, I can create a workaround for
this (allowing scripts that don't set a given variable to be
recompiled each time), but I'd rather do it all The Right Way if noone
sees a need that it be otherwise.
Posted: Wed Jan 12, 2000 2:32 pm Post subject: [Asterisk] Perl issues
Quote:
First off, only the development branch of Perl supports the
concurrency features needed, and it must be compiled with USE_THREADS
and IMPLICIT_CONTEXT.
To use an older perl requires that it still be compiled with
MULTIPLICITY, _and_ be mutex-protected (making all perl-using threads
wait in line). I think everyone agrees that this is a Bad Thing.
If you're using perl for applications, you do *not* need to be threadsafe
in general, because only one thread has control of a channel at any given
time. Asterisk in general certainly does some threadsafe protections
around certain variables, like lists of channels, etc, but the
applications in general do not need to know about threads (except if you
want to do nice cleanup on a forced removal which isn't even really
required, although it is nice).
Quote:
Anyhow, I'm anticipating that not everyone will want to recompile the
latest perl for the sake of working on Asterisk; I can add support for
using an old perl (so the folks who are just playing with their one
OSS device can be fine), if anyone deems that appropriate. Also up for
discussion are some makefile changes -- embedding perl requires a
few. Should these changes be made for everyone, or just when a
perl-enabled Asterisk is being built?
Depends on what those changes are. If perl support doesn't negatively
affect Asterisk -- and is reasonably stable -- then I think it should
always be built (assuming they have a proper version of perl installed)
and if they don't, then don't build it.
Quote:
Next, regarding some speed-related issues -- I'm doing something
rather similar to mod_perl here (though quite a bit simpler) and
reusing compiled code between calls. This means that any perl that's
not clean for this (requires that some global variable be set to an
initial value each startup but doesn't reset it after a run) will need
modifying. If someone needs it to be so, I can create a workaround for
this (allowing scripts that don't set a given variable to be
recompiled each time), but I'd rather do it all The Right Way if noone
sees a need that it be otherwise.
You know, I almost wonder whether something like FastCGI wouldn't be
a better architecture. I've got a bad taste for mod_perl ever since I
tried to work with it, and trying to get scripts to wok with mod_perl
isn't always easy. I would definitely make it an option if I were you.
On Wed, Jan 12, 2000 at 08:32:08AM -0600, Mark Spencer wrote:
Quote:
> First off, only the development branch of Perl supports the
> concurrency features needed, and it must be compiled with USE_THREADS
> and IMPLICIT_CONTEXT.
>=20
> To use an older perl requires that it still be compiled with
> MULTIPLICITY, _and_ be mutex-protected (making all perl-using threads
> wait in line). I think everyone agrees that this is a Bad Thing.
=20
If you're using perl for applications, you do *not* need to be threadsafe
in general, because only one thread has control of a channel at any given
time. Asterisk in general certainly does some threadsafe protections
around certain variables, like lists of channels, etc, but the
applications in general do not need to know about threads (except if you
want to do nice cleanup on a forced removal which isn't even really
required, although it is nice).
But you've got applications going on different channels
simultaneously, and presumably would want more than one of them to be
perl-based at a time. Standard builds of the perl library have all
sorts of globals (which it doesn't bother to lock) and other Really
Ugly Stuff from a threading POV, making it quite necessary to only use
one PerlInterpreter at a time (of course, on a standard build, if you
don't have MULTIPLICITY defined, you can only _have_ one).
Quote:
> Anyhow, I'm anticipating that not everyone will want to recompile the
> latest perl for the sake of working on Asterisk; I can add support for
> using an old perl (so the folks who are just playing with their one
> OSS device can be fine), if anyone deems that appropriate. Also up for
> discussion are some makefile changes -- embedding perl requires a
> few. Should these changes be made for everyone, or just when a
> perl-enabled Asterisk is being built?
=20
Depends on what those changes are. If perl support doesn't negatively
affect Asterisk -- and is reasonably stable -- then I think it should
always be built (assuming they have a proper version of perl installed)
and if they don't, then don't build it.
Regarding "reasonably stable", much of the threading stuff is one of
those "should-be-stable-by-5.006" things. Until I actually get it
working I can't comment on how stable it'll actually be; However, I
don't want to promise much just yet (at least, not with the present
releases of perl).
I'm still inclined to make perl optional, though -- if for no reason
other than the increased memory requirements. Maybe an autoconf script
or something of that sort would be appropriate (for both version
checking and allowing user preference).
Quote:
> Next, regarding some speed-related issues -- I'm doing something
> rather similar to mod_perl here (though quite a bit simpler) and
> reusing compiled code between calls. This means that any perl that's
> not clean for this (requires that some global variable be set to an
> initial value each startup but doesn't reset it after a run) will need
> modifying. If someone needs it to be so, I can create a workaround for
> this (allowing scripts that don't set a given variable to be
> recompiled each time), but I'd rather do it all The Right Way if noone
> sees a need that it be otherwise.
=20
You know, I almost wonder whether something like FastCGI wouldn't be
a better architecture. I've got a bad taste for mod_perl ever since I
tried to work with it, and trying to get scripts to wok with mod_perl
isn't always easy. I would definitely make it an option if I were you.
Mmm-ker.
I've had another architecture idea bumping 'round in my head... I'll
see 'bout writing it down (with a few examples) and seeing if you
don't find it easier -- it strikes me as=20
--bCsyhTFzCvuiizWE
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Posted: Wed Jan 12, 2000 6:52 pm Post subject: [Asterisk] Perl issues
Quote:
But you've got applications going on different channels
simultaneously, and presumably would want more than one of them to be
perl-based at a time. Standard builds of the perl library have all
sorts of globals (which it doesn't bother to lock) and other Really
Ugly Stuff from a threading POV, making it quite necessary to only use
one PerlInterpreter at a time (of course, on a standard build, if you
don't have MULTIPLICITY defined, you can only _have_ one).
Oh!! That definitely sucks. In the mean time we could do something along
the lines of FastCGI... How does mod_perl handle it?
Quote:
I'm still inclined to make perl optional, though -- if for no reason
other than the increased memory requirements. Maybe an autoconf script
or something of that sort would be appropriate (for both version
checking and allowing user preference).
Perl should be a module that is loaded in asterisk at run time. There
should be no penalty for compiling it, only if you load it. And if you
don't want to load it, do "noload=mod_perl" or whatever in your
modules.conf.
Quote:
Mmm-ker.
I've had another architecture idea bumping 'round in my head... I'll
see 'bout writing it down (with a few examples) and seeing if you
don't find it easier -- it strikes me as
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum