so i suggest we define our own APACHE_IS_20 at the beginning, which we
set to 1 if STANDARD20_MODULE_STUFF is set. that should be safe for now,
and can be adapted easily. d'accord?
Looks ok
so- interestingly, not putenv() crashes, but getenv(). the only ref's i
could find with google were about some mod_php/mod_perl incompatibility
because perl "fixed" the old, broken putenv and allocated its own memory
for the environment (freeing the old), breaking mod_php. you're not
doing sth like this, are you?
Not at all :)
Maybe you could add some traces in neko/libs/std/sys.c : get_env to
check if we go through this function and which env string is/are requested ?
as a workaround, i define MOD_NEKO=1 in bash before i start apache2. on
gentoo, i have to add MOD_NEKO (and NEKOPATH) to KEEPENV to have the
initscript pass them on to apache.
there is a module called mod_env which adds configuration statements
like "SetEnv" and "UnsetEnv" which supposedly set the environment for
cgi processes. it doesn't have effect on mod_neko, though. the new
environment is passed on by mod_cgi with exec[ve].
Yes Mod_neko is not a CGI script, it's not affected by mod_env.
i'm unsure what to do here. obviously, setting MOD_NEKO in the
environment "around" apache is a ugly workaround.
Yes, I would like to find an answer here since it might alter other
functionalities as well.
If I understand :
* getenv crash
* only if putenv was done ??
> > * context.h doesnt exist with apache2, but it doesnt seem to be
neccessary.
> context.h is part of Neko sources, and is also used in mod_neko.
> This is a small API that is saving a per-thread variable. It's right
now
> only implemented on Windows, the Linux implementation is "empty" and
> shoud be completed in order to make Mod_neko2.0 work. In fact, this
is
> needed to be able to be able to run multiple NekoVM at the same
time.
a-ha. can you point me at a linuxy way to set thread-local variables?
with so many threading libs around, i should probably scan the apache
sources for hints? do you have any thoughts on this also regarding
integration of some threading lib (pthreads?), or of other libs that use
threads internally?
I'm not sure which method is best to store Thread-Local variables on
Linux/OSX. Maybe Pthreads but if it requires additional dependencies,
maybe native threads are better ?
> Eg, neko fails awkwardly when i use callEx from a
gstreamer callback function (even when i use a mutex to assure nothing
neko is executed twice at the same time)-- does boehmgc have any problem
if gc functions are called from threads that did not allocate the
variables?
You need to ensure that the local VM is set (using neko_vm_select)
before using callEx. There should not be any GC issue.
> Don't hesitate to ask if you have more questions. When everything is
> working correctly I will apply the patch to Mod_neko sources.
sweet.
what do you suggest to do about the build procedure here? i currently
use apxs2 (the "apache extension tool") to compile, the least we must do
is to append the output of apr-config --libs --cflags to our gcc line..
Uhm.
You can't simply have the user specify an include path ? That would fit
better the current system for compiling neko libraries.
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
