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 control should be done with special commands and not with exit/return/break/whatever standard commands. The upper functionality has something to do with the standard exit, but they are heavy and have big consequences. - Solution 2 - But what about the following remarks: The main reason for me to define something reasonable to exit are third-party libraries which the user does not control. Those libraries may use "exit" to say: no way to continue, anything messed up, get out. For example, a data base driver may be in a situation where a transaction is in an unknown state and it just stops all the mess. The later thinking gives arguments to define exit as "abort thread or process". It is also interesting what happens to exit calls on the C level, libraries may use: Tcl_Exit, Tcl_ExitThread Thank you, Harald Am 16.09.2015 um 00:54 schrieb Massimo Manghi: > I've been thinking of this issue and I want to manifest my proposal for > changing the way exit works with Rivet. > > First of all I think the command exit, being a Tcl core command must be > kept in some form and not just deleted. We rather should give it a > meaning. The first idea that came up to me was to let exit behave like > ::rivet::abort_page, giving it a structured error code the way we did > with ::rivet::redirect. The exit command synopsis is easy > > NAME > exit - End the application > > SYNOPSIS > exit ?returnCode? > > > we may add a ::rivet::exit command that is meant to shadow the core > command accepting the same error code parameter, which interrupts the > script execution and passes control to the AbortScript (if defined). > Through the command ::rivet::abort_code the exit return code can be > retrieved and the call to exit detected. It doesn't add a special value > to the command set, it might look like syntactic sugar for a special > form of ::rivet::abort_page, the way 'redirect' builds a dictionary with > a key 'error_code' set as 'redirect' and then a key 'location' with the > URL it redirects to. It just tries to give a meaning to the command exit > that would fit into Rivet and Apache > > The new form of exit should store in the thread status a dictionary like > > error_code -> exit > return_code -> ?returnCode? > > I stick to the idea that in some cases (development, debugging etc) > could be useful to have a way to terminate a process. In order to stress > the whole concept that exit is not something to be used carelessly in > that way we could introduce a new global configuration parameter > ExitTerminatesProcess (by default set to Off, naturally) as a way to > highlight the proper usage of this option. > > Since abort_page returns a Tcl error which is trapped to fire > AbortScript the catch command could prevent this to happen. I think that > at least in the case of the error raised by 'exit' (but I would favor a > general usage of it) we should give the programmer the option of a > abort-page aware catch command that should fall back to the core catch > command if the error is anything not generated by either 'redirect' > 'abort_page' or 'exit' > > -- Massimo > > > > > On 09/12/2015 12:23 AM, Massimo Manghi wrote: > [...] >> >> We may compromise between the case of removing it altogether and having >> an immediate process exit. For example we might integrate it with the >> abort_page command or take inspiration from the recently introduced >> ::rivet::redir command. The new form for exit might interrupt instantly >> the script execution and signal a deferred process/thread exit after the >> request processing finished. But even in these scheme 'exit' should be >> advertised for what would be in Rivet: a solution to be used only in >> extreme cases >> >> -- Massimo >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org > For additional commands, e-mail: rivet-dev-h...@tcl.apache.org > -- ELMICRON Dr. Harald Oehlmann GmbH Koesener Str. 85 06618 Naumburg Germany Phone: +49 (0)3445 78112-0 Fax: +49 (0)3445 78112-19 www.Elmicron.de German legal references: Geschaeftsfuehrer: Dr. Harald Oehlmann, Jens Oehlmann UST Nr. / VAT ID No.: DE206105272 HRB 212803 Stendal --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
