Re: [go-nuts] Orderly exit

On February 24, 2021 11:37:05 PM UTC, robert engels wrote: >A simple slice OOB causes a panic - this is why many robust servers >will catch & recover so a single OOB due to bug triggered by rare >input/state doesn’t crash the server for 1000’s of users. It might >still cause problems due to resou

Re: [go-nuts] Orderly exit

A simple slice OOB causes a panic - this is why many robust servers will catch & recover so a single OOB due to bug triggered by rare input/state doesn’t crash the server for 1000’s of users. It might still cause problems due to resource exhaustion, but properly designed exception/error handling

Re: [go-nuts] Orderly exit

You can read the section ‘Apache Vulnerabilities’ and the difference in forking vs multi-threader Apache configuration and how that triggers a DoS. See https://www.feistyduck.com/library/apache-security/online/apachesc-CHP-5.html > On Feb 24, 2021, at 5:16 PM, robert engels wrote: > > I’m sorr

Re: [go-nuts] Orderly exit

On February 24, 2021 11:16:46 PM UTC, robert engels wrote: >I’m sorry but that is not correct. If you have a “server process” that >handles requests for 1000’s of clients - terminating the process due to >an exception/panic easily leads to a DoS attack. The bad actor only >needs to send similar r

Re: [go-nuts] Orderly exit

I’m sorry but that is not correct. If you have a “server process” that handles requests for 1000’s of clients - terminating the process due to an exception/panic easily leads to a DoS attack. The bad actor only needs to send similar requests infrequently to affect thousands of users - especially

Re: [go-nuts] Orderly exit

On February 24, 2021 8:00:36 PM UTC, Robert Engels wrote: >Depending on other infrastructure that can easily lead to easy DoS >attacks. Utter nonsense, more likely the opposite, if any difference at all. -- You received this message because you are subscribed to the Google Groups "golang-nut

Re: [go-nuts] Orderly exit

Depending on other infrastructure that can easily lead to easy DoS attacks. > On Feb 24, 2021, at 12:15 PM, Kevin Chadwick wrote: > > On 2/24/21 9:53 AM, roger peppe wrote: >> On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick > > wrote: >> >>I only instigate panic m

Re: [go-nuts] Orderly exit

On 2/24/21 9:53 AM, roger peppe wrote: > On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick > wrote: > > I only instigate panic manually for one thing. Perhaps that will change, > but > I doubt it. > > If I want to send out or write a log to disk then I will ca

Re: [go-nuts] Orderly exit

On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick wrote: > I only instigate panic manually for one thing. Perhaps that will change, > but I doubt it. > > If I want to send out or write a log to disk then I will call panic rather > than os.exit, upon a log.fatal scenario. Think buffered go routine logg

Re: [go-nuts] Orderly exit

> So you should probably disregard the sentinel-panic idea, > runtime.Goexit seems strictly superior) Thank you. I shall look into those. WRT Goexit. I was hoping a defer in main would run also. Thinking about it. I shall have to ponder about the relationship of panic and process groups too

Re: [go-nuts] Orderly exit

(PS: I've only learned about runtime.Goexit after I came up with the sentinel-panic pattern. I've been thinking for a while, that it is probably a better choice, for various reasons. And after testing it out, I do think it's strictly superior. So you should p

Re: [go-nuts] Orderly exit

On Tue, Feb 23, 2021 at 1:10 PM Kevin Chadwick wrote: > Is it possible to call panic in a way that does not kill the process like > os.Exit, but without log pollution? I am solely thinking of manually instigated panics, so a noop panic called > something like terminate? > You can `recover`. I

[go-nuts] Orderly exit

I only instigate panic manually for one thing. Perhaps that will change, but I doubt it. If I want to send out or write a log to disk then I will call panic rather than os.exit, upon a log.fatal scenario. Think buffered go routine logging. Saving the coder from having to think about it, once in