On Thu, May 9, 2019 at 9:03 AM Nathanael Curin <n.cu...@capitaldata.fr> wrote: > > Hi everyone, > > Searching Go's documentation and this group didn't really help me find what > I'm looking for so, here goes. > > I'd like to implement a timeout system on every request to my HTTP server > that would work like this : > > Receive an http.Request, perform initial checks on validity > Start a timeout time.Timer of N milliseconds > Send the Request + a context.Context to a goroutine, answering through a > response channel when its job is done > Wait in a Select for either channel (timer.C or responseChannel)
You can use context.WithTimeout() for this. You can do: request=request.WithContext(context.WithTimeout(request.Context(), 100*time.Millisecond)) and send the request to your goroutine. The context will be canceled after the timeout. During processing, you should check if the context is still alive and return if it timed out. Each timer will run it its own goroutine, so it'll take 2K of memory for each. I don't know how accurate those timers would be, though. You could record and log the difference between the time you start processing and a timeout happens and see how well it scales. When the context times out, the select waiting on the cancel channel will wake up, and then you can execute any cleanups necessary. A timeout will not "unschedule" a goroutine, it'll simply close a channel. > > If the Select goes in the responseChannel branch, I can close my timer, and > write my HTTP Response. Otherwise, my timer expired, I have to answer to my > HTTP client, close my Context, and simply discard whatever is sent to the > responseChannel afterwards, in the event that this actually happens. > > A few questions about this implementation : > > (Technical stuff) How exactly are Timers and Tickers implemented in the > runtime / in the OS? Is there a hard limit? Soft limit? Is it CPU-bound? > Core-bound?... > If I received, let's say, 5000 queries per second, and every query has 100ms > of timeout (so, 500 potential simultaneous timers - in practice, probably a > bit more), would every timer really be perfectly stable? How can you make > sure of this, debug, and monitor timer expirations? > Last but not least, admitting that Go's scheduler actually answers perfectly > fine at the timer's expiration, how can I make sure that the end of the code > after the Select/Case runs without stopping? Can the routine get > "unscheduled" after the timer's expiration, but before writing the HTTP > Response for some reason? > > Thanks for the insight. Don't hesitate to ask for precisions if necessary. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/cdf6b347-bfb9-44ce-b4d6-9d06602b1738%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqou1ZZQaRgBfitBkRPx5i6nObmW%2B9wSRiLS-FMv%3DfY22g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
