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 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 uncaught traceback within the guts of our top level
traceback-handling code.

And we don't do exit in above situations. Application reports HTTP 500
result code with standard message like "error processing request".

At some request later database is reconnected. It doesn't require worker
to restart.

Uncaught error in this one request may not repeat with next request. The
worker doesn't exit.


I think we all agree that exit could turn out to be the bad programmer's way to sweep the dust under the carpet

I'm just trying to design mod_rivet so that we can use Tcl to do web programming with the Apache HTTP web server, and since it's all about Tcl we have to give a predictable meaning to Tcl's core command [exit]. We could spend hours deprecating its usage (quite correctly), but the command is there and it must work in away that has to be closest to the way the same command works with tclsh.

There are situations where worker exit doesn't help to recover from
detected problem. Say request to external service returns unexpected
result repeatedly.

right, that's a possible status that has to be handled by design


But maybe to terminate worker is simpler and/or safer ..


I think we are misunderstanding each other here: what do we mean with 'worker'? An interpreter, a thread or a whole process? We used to terminate an interpreter and its thread (or process for the prefork bridge in 2.3.0) so far, but the Tcl core team is now telling us we are better off if we give up deleting interpreters and instead terminate a whole process, lest we are creating a possible memory leak.

 -- Massimo

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Reply via email to