Nicolas,
> > issues remaining:
> > * make it so the same source file can be used for apache1 and 2.
>
> Yes, for that we need to check in the httpd.h, there must be some
> version definition in the header, and depending on it we can use
> #ifdef/#else to compile for either 1.3 or 2.0
right. although i'm rather unsure what to use. apr's ap_release.h
defines (in my case)
#define AP_SERVER_MAJORVERSION "2"
#define AP_SERVER_MINORVERSION "0"
#define AP_SERVER_PATCHLEVEL "55"
,
but #if AP_SERVER_MAJORVERSION >= 2
will not work obviously, as "2" is no integer constant.
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?
> > * putenv("MOD_NEKO=1") crashes my apache2. so we need to find
another way to signal the cgi module that it's running in apache.
>
> That's very strange. putenv is a pretty much standard C function. I
> don't see how it could crash your apache. If you try something else,
> like putenv("SOMETHINGELSE=1"); does it crash too ? That might be a
> problem related to linking, for example apache2 having a "putenv"
method
> that is called instead of the libc one.
i could find no references to putenv within apache. setting something
else crashes it too, with the following gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22237)]
0xb7b8e43a in getenv () from /lib/libc.so.6
(gdb) bt
#0 0xb7b8e43a in getenv () from /lib/libc.so.6
#1 0x0808fcda in _IO_stdin_used ()
#2 0x00000008 in ?? ()
#3 0x48534e28 in ?? ()
#4 0x00000008 in ?? ()
#5 0x0809a400 in ap_hack_unixd_accept ()
#6 0x080a4e28 in ?? ()
#7 0x080a2ea0 in ?? ()
#8 0xbfb63188 in ?? ()
#9 0x0806a79a in ap_register_hooks ()
#10 0x0808fcda in _IO_stdin_used ()
#11 0x080a4e28 in ?? ()
#12 0x08099310 in ap_prelinked_modules ()
#13 0x0806e5f2 in main ()
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?
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].
i'm unsure what to do here. obviously, setting MOD_NEKO in the
environment "around" apache is a ugly workaround.
> > * 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? 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?
> > * send_headers is not yet implemented, i haven't figured how its
done in apache2
> Maybe headers are sent automatically when some data is printed. It
means
> then that you don't need it, although you should continue to manage
the
> headers_sent flag.
header seem to be sent fine, so, ok.
> 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..
-dan
--
http://0xDF.com/
http://iterative.org/
--
Neko : One VM to run them all
(http://nekovm.org)
