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 did everything
possible in order to keep it, because even though it was a bad way to
escape a bad situation it offered a last resort route to panic and
restart a child/thread. That's the answer I gave to myself. Naturally
you have to be aware of what your doing and use it only for very special
and hopefully unlikely cases
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
On 09/11/2015 08:41 PM, Damon Courtney wrote:
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 serving the page, and it worked! It worked
exactly like I hoped it would. What I didn’t understand was that I
was causing the entire child to exit. Of course I was. I just didn’t
know it because I hadn’t thought it through.
Most of the time when you want to exit a Rivet request, what you
really want is to just stop serving the request and bail. But going
to all the trouble to exit the interp and kill off the child in the
proper way sounds unnecessary.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
