Separate virtual interpreters are amazingly cool. Using them,
fiddling with auto_path, and using git we're able to give each
developer their own Rivet interpreters with a private library path
that gets searched first, their own webpages, and so forth. It's great.
But we're having a problem that when we do an apachectl stop all of
the children that have served webpages dump core. The problem is that
outputproc is getting called by the flush activities triggered by the
call to Tcl_Finalize() as part of the shutdown. There isn't really a
request structure so it quickly dereferences a null pointer and that
triggers a coredump.
Doing some debugging, I've determined that the Tcl channel that Rivet
maps to Apache's ap_rwrite and such, its close routine is getting
called prior to the attempt to flush this data.
What's weird is that the data that it's trying to write is the same as
the last webpage the child generated.
I'm continuing to investigate because I want to know why it's
happening, although it's also reasonable to make the closeproc set a
"closed" flag that the outputproc would honor. The outputproc could
also very easily detect that the request structure isn't real, but the
big question is why is it getting called in the first place.
I mention it here in the hopes that someone will have a flash of
insight and/or knows the answer.
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
