Good point on the implementing side of things, it's cleaner. I'm still really curious of the limits and implementation details - There has to be some kind of limit where things start to become erratic. If anyone wants to chime in :)
Le jeudi 9 mai 2019 17:23:27 UTC+2, Burak Serdar a écrit : > > On Thu, May 9, 2019 at 9:03 AM Nathanael Curin <n.c...@capitaldata.fr > <javascript:>> 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 golan...@googlegroups.com <javascript:>. > > 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/cccb64eb-2fc5-403e-a663-7f12996f1b38%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
