> > > * Even if we did this, the bug only turns into a packet of death. A packet >> of death on this scale is of almost the same level of annoyance and chaos. >> (Witness this week's firestorm about an email packet of death on some Cisco >> something or other.) >> >> > I did address this. If each request is bounds checked and memory isolated, > then a failure is just an exception of some kind and we handle this as we > would any other exception. You could also just fork the process for each > incoming request and obtain the same semantics. >
The server crashes - that's how we handle "any other exception", as a rule. That's a lot of work to convert "leaking session keys" into "crashes the server". Especially since you turn "maybe leaks a session key on repeated tries" into "crashes the server immediately with a single packet". Maybe the result actually makes things worse. :) I don't know what you mean by "just fork the process". First, if you're transpiling into Go, that's not a good strategy. Second, are you suggesting the transpiler would automatically rewrite the request handling loop to avoid the harm of crashes? Thomas -- memegen delenda est -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
