Re: Tcl exit command in mod_rivet

2015-09-17 Thread Anton Osennikov
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

Re: Tcl exit command in mod_rivet

2015-09-17 Thread Massimo Manghi
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

Re: Tcl exit command in mod_rivet

2015-09-17 Thread Massimo Manghi
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

Re: Tcl exit command in mod_rivet

2015-09-16 Thread Harald Oehlmann
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

Re: Tcl exit command in mod_rivet

2015-09-16 Thread Karl Lehenbauer
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

Re: Tcl exit command in mod_rivet

2015-09-16 Thread Massimo Manghi
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

Re: Tcl exit command in mod_rivet

2015-09-16 Thread Karl Lehenbauer
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

Re: Tcl exit command in mod_rivet

2015-09-16 Thread Anton Osennikov
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

Re: Tcl exit command in mod_rivet

2015-09-16 Thread Anton Osennikov
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

Re: Tcl exit command in mod_rivet

2015-09-11 Thread Damon Courtney
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

2015-09-11 Thread Anton Osennikov
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

2015-09-11 Thread Anton Osennikov
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

2015-09-11 Thread Massimo Manghi
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

2015-09-11 Thread David Welton
> 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

2015-09-11 Thread Damon Courtney
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

2015-09-11 Thread Massimo Manghi
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

2015-09-11 Thread Karl Lehenbauer
> 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

2015-09-11 Thread Massimo Manghi
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