Re: Tcl exit command in mod_rivet

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,

Re: Tcl exit command in mod_rivet

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

Re: Tcl exit command in mod_rivet

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

Re: Tcl exit command in mod_rivet

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

Re: Tcl exit command in mod_rivet

> 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

Re: Tcl exit command in mod_rivet

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

Re: Tcl exit command in mod_rivet

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

Re: Tcl exit command in mod_rivet

> 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

Re: Tcl exit command in mod_rivet

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