16.09.2015 23:33, Anton Osennikov пишет:
16.09.2015 19:37, Karl Lehenbauer пишет:
I want to affirm your comments from the 11th that there needs to be a
way to to terminate the child process or thread if code detects that
things have gotten wonky.
maybe to terminate worker is simpler and/or
Hi
before answering I want to tell everybody that I am and I will be very
busy with my job for a week or so. If you notice some latency in my
response timing be patient.
On 09/16/2015 08:33 PM, Anton Osennikov wrote:
Hi!
16.09.2015 19:37, Karl Lehenbauer пишет:
I want to affirm your
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
Massimo,
thank you for the ideas.
- Solution 1-
For me, it also feels natural to give exit the meaning of abort_page.
I am also with you, that deeper control of threads and processes is
helpful, to just say: clean up, this thread/process is messed up, apache
will anyway start a new one. This
Hi Massimo,
I want to affirm your comments from the 11th that there needs to be a way to to
terminate the child process or thread if code detects that things have gotten
wonky. We do this, for instance, on failure to obtain a database connection
during page processing startup and on any
On 09/16/2015 04:37 PM, Karl Lehenbauer wrote:
Hi Massimo,
I want to affirm your comments from the 11th that there needs to be a
way to to terminate the child process or thread if code detects that
things have gotten wonky. We do this, for instance, on failure to
obtain a database connection
On 9/16/15, 11:58 AM, "Massimo Manghi" wrote:
>
>
>On 09/16/2015 04:37 PM, Karl Lehenbauer wrote:
>> Hi Massimo,
>>
>> I want to affirm your comments from the 11th that there needs to be a
>> way to to terminate the child process or thread if code detects that
>> things
Hi!
16.09.2015 19:37, Karl Lehenbauer пишет:
I want to affirm your comments from the 11th that there needs to be a
way to to terminate the child process or thread if code detects that
things have gotten wonky. We do this, for instance, on failure to
obtain a database connection during page
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
I think the ability to create the interp up front (on startup) is really
useful. Yes, “lazy” creation of the interp on first request could be a thing
too, but I think maybe we need a preference here. In my case, I’m currently
doing “lazy” loading, not of the interpreters, but of my code. So,
11.09.2015 14:18, Massimo Manghi пишет:
Interpreters will be created and initialized only when the first request
for a specific virtual host comes in
I doubt that to initialize an intrepreter when request comes is a good
solution.
I'm running a custom rivet child init script now which
11.09.2015 14:18, Massimo Manghi пишет:
Then, in order to mitigate the possible interpreter
termination/initialization storm that might ensue an inappropriate usage
of the 'exit' command
But what's the known *appropriate* usage of the 'exit' command inside rivet?
If there isn't one, maybe
As no answer or suggestion followed this proposal I will implement it
and commit it in trunk. Then, in order to mitigate the possible
interpreter termination/initialization storm that might ensue an
inappropriate usage of the 'exit' command (we don't delete interpreters
anymore but child exit
> The problem with this approach is that the “init” can take a couple seconds
> with all the bits I’m loading in, which means the first person to hit a new
> interp is getting a really crappy experience. I would prefer to do all the
> init on startup of the child and interp so that the child
I’m with Anton here. I don’t think [exit] within a Rivet interp should be
possible. It’s just not something you should be doing, and in almost all cases,
you’re not doing what you think you’re doing.
I learned this hard lesson back in the NeoWebScript days. I would call [exit]
to terminate
Anton's point is very good.
The reason why I kept exit? Because it was already there and someone
could have used it to bail out of an application's inconsistent state
that had no obvious way to recover (the closer analogy I have in mind is
something like an 'assert' statement) That's why I
> On Sep 11, 2015, at 4:18 AM, Massimo Manghi wrote:
>
> As no answer or suggestion followed this proposal I will implement it and
> commit it in trunk. Then, in order to mitigate the possible interpreter
> termination/initialization storm that might ensue an
On 09/11/2015 02:49 PM, Karl Lehenbauer wrote:
Creating interpreters only when the first request for specific
virtual host comes in is a great idea! (I presume this is
specifically only when running with separate virtual interpreters.)
Not deleting the interpreter on process exit is a nice
18 matches
Mail list logo