On 09/16/2015 07:38 PM, Anton Osennikov wrote:
12.09.2015 3:16, Massimo Manghi пишет:
Then why did it stop working the way it worked with Tcl 8.5? I think
this is the question to be answered.
As far as I know, Itcl3 does lazy object creation, i.e. it only creates
object stub command instead of real object at first. This stub creates
real object later when and *if* it is needed. I think Itcl4 could stop
doing so. I think I can restore similar behaviour in my app on my own
where it's hardly needed.
This remark should be addressed to the core team and more specifically
to the person who is looking after Itcl. Is still Arnulf the person
behind Itcl?
As a possible workaround I'm looking for a way to pre-load my sources
before actual request comes now..
This is the way ChildInitScript works now, it runs before requests come
in, why didn't it work for you?
It works. Just wasn't used before.
I reworked the app to allow code loading in ChildInitScript. It's OK.
Apache restart takes rather long time, however.
Pre-loading app code in ChildInitScript has it's drawbacks.
During development, code with errors gives error messages repeated for
every worker process.
yes, this is what happens when I talked of initialization storm. I don't
alternatives beside carefully tailoring the severity of your messages
and/or setting the logging threshold to a higher severity level.
When there are several apps pre-loaded, starting extra worker processes
due to some request storm for *single* app causes loading of *several
apps* into *every extra worker* instead of loading just one app into them.
I've done also some experiments to load app code in ServerInitScript.
Stumbled upon strange errors. Abandoned this.
what errors exactly? Can you track down what happened?
We have also the GlobalInitScript
(actually only when separate virtual interpreters are disabled)
Is there any difference between GlobalInitScript and ChildInitScript
defined outside any of VirtualHost's?
GlobalInitScript is not Virtual host specific, ChildInitScript are. If
SeparateVirtualInterps is On virtual hosts specific interpreters are
created as slave interpreters in 2.2.3 and you cannot assume they are
inheriting all the initialization done by GlobalInitScript. In 2.3.0 the
mechanics is different and could change before release. Virtual host
specific interpreters are not created as slave interpreter but rather as
separate interpreters. GlobalInitScript works only for the first virtual
host. We should discuss this point and understand how it should be changed
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]