D - Unsafe and doomed

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Sunday, 5 January 2014 at 15:19:15 UTC, H. S. Teoh wrote:
> Isn't that usually handled by running the webserver itself as a 
> separate
> process, so that when the child segfaults the parent returns 
> HTTP 501?

You can do that. The hard part is how to deal with the other 99 
non-offending concurrent requests running in the faulty process.

How does the parent process know which request was the offending, 
and what if the parent process was the one failing, then you 
should handle it in the front-end-proxy anyway?

Worse, cutting off all requests could leave trash around in the 
system where requests write to temporary data stores where it is 
undesirable to implement a full logging/cross-server 
transactional mechanism. That could be a DoS vector.

> HTTP link? I rather the process segfault immediately rather than
> continuing to run when it detected an obvious logic problem 
> with its own
> code).

And not start up again, keeping the service down until a bugfix 
arrives? A null pointer error can be a innocent bug for some 
services, so I don't think the programming language should 
dictate what you do, though you probably should have write 
protected code-pages with execute flag.

E.g. I don't think it makes sense to shut down a trivial service 
written in "Python" if it has a logic flaw that tries to access a 
None pointer for a specific request if you know where in the code 
it happens. It makes sense to issue an exception, catch it in the 
request handler free all temporary allocated resources and tell 
the offending client not to do that again and keep the process 
running completing all other requests. Otherwise you have a DoS 
vector?

It should be up to the application programmer whether the program 
should recover and complete the other 99 concurrent requests 
before resetting, not the language. If one http request can shut 
down the other 99 requests in the process then it becomes a DoS 
vector.