I don’t think your requirements are completely specified. For example, you say the timeout is 100ms - nothing is ever exact - what is the tolerance in the delay before it is cancelled ? Are the calls in the handler even cancelable? What type of hardware (64+ cores?)
I think this is why you are hearing crickets. > On May 10, 2019, at 7:05 AM, Nathanael Curin <n.cu...@capitaldata.fr> wrote: > > 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> >> 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. >> > 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. -- 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/F55588DC-4BC9-4D7E-9E33-AEC2929AA85A%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
