On 6/1/17 2:00 PM, Walter Bright wrote:
On 6/1/2017 2:53 AM, Vladimir Panteleev wrote:
3. Design your program so that it can be terminated at any point
without resulting in data corruption. I don't know if Vibe.d can
satisfy this constraint, but e.g. the ae.net.http.server workflow is
to build/send the entire response atomically, meaning that the
Content-Length will always be populated. Wrap your database updates in
transactions. Use the "write to temporary file then rename over the
original file" pattern when updating files. Etc.
This is the best advice.
I.e. design with the assumption that failure will occur, rather than
fruitlessly trying to prevent all failure.
Indeed it is good advice. I'm thinking actually a good setup is to have
2 levels of processes: one which delivers requests to some set of child
processes that handle the requests with fibers, and one which handles
the i/o to the client. Then if the subprocess dies, the master process
can both inform the client of the failure, and retry other fibers that
were in process but never had a chance to finish.
Not sure if I'll get to that point. At this time, I'm writing an array
wrapping struct that will turn all range errors into range exceptions.
Then at least I can inform the client of the error and continue to
handle requests.
-Steve
