Re: [go-nuts] [design] HTTP server serving heavy computing : Handle HTTP request closed prematurely

[Thomas S]

Thank you, that helps a lot.



Le vendredi 19 juin 2020 15:49:22 UTC+2, Andrei Tudor Călin a écrit :
>
> Goroutines can only be stopped if they cooperate. They have no user-facing 
> identity or a handle by which they can be stopped. To cooperate, they need 
> to be checking some kind of cancellation flag or channel, periodically. 
> These days, for HTTP servers, that channel is the request context, since 
> CloseNotifier is deprecated.
>
> To reduce the potential cost of using select in a tight processing loop, 
> you could select on the channel only every N iterations, or maybe after T 
> time has passed since you last checked. If selects are prohibitively 
> expensive for you, you could check an atomic flag instead, and control the 
> flag through an external goroutine which waits for <-ctx.Done(). There is a 
> little bit more machinery here, but I expect this to be at least a little 
> faster than a select.
>
> In any case, these things must happen explicitly: code that wants to be 
> responsive to cancellation signals must be programmed as such.
>
>
> On Fri, Jun 19, 2020 at 3:58 PM Thomas S > 
> wrote:
>
>> Hello,
>>
>> I have an HTTP server providing heavy algorithms. Sometimes, the clients 
>> closes the connection prematurely, before the end of computing.
>>
>> Note : Sometimes the client consuming these algorithms want to stop the 
>> process if the solution is not found before X minutes for example.
>>
>> This article : 
>> https://gianarb.it/blog/go-http-cleanup-http-connection-terminated
>> shows how to use the "http.CloseNotifier" chan to receive the signal 
>> about the premature end of connection.
>>
>> *However*,
>>
>> The algorithm is made of several thousands of lines, called proceduraly, 
>> and sometimes even calling parallel computing on goroutines and recursive 
>> functions.
>>
>> It means that I should share the chan everywhere, to every functions or 
>> almost, insert a boilerplate of channel check frequently in the algorithm, 
>> and make an exit if needed.
>>
>> It seems to me pretty awful. Am I missing something ?
>>
>>
>> Thanks a lot,
>>
>> -- 
>> 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/ad1221ad-0ac6-4282-a708-20ab8d49fa5co%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Andrei Călin
>

-- 
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/98a4a95a-5a08-4ff7-85d9-0c02869e6a43o%40googlegroups.com.

Re: [go-nuts] [design] HTTP server serving heavy computing : Handle HTTP request closed prematurely

[Andrei Tudor Călin]

Goroutines can only be stopped if they cooperate. They have no user-facing
identity or a handle by which they can be stopped. To cooperate, they need
to be checking some kind of cancellation flag or channel, periodically.
These days, for HTTP servers, that channel is the request context, since
CloseNotifier is deprecated.

To reduce the potential cost of using select in a tight processing loop,
you could select on the channel only every N iterations, or maybe after T
time has passed since you last checked. If selects are prohibitively
expensive for you, you could check an atomic flag instead, and control the
flag through an external goroutine which waits for <-ctx.Done(). There is a
little bit more machinery here, but I expect this to be at least a little
faster than a select.

In any case, these things must happen explicitly: code that wants to be
responsive to cancellation signals must be programmed as such.


On Fri, Jun 19, 2020 at 3:58 PM Thomas S  wrote:

> Hello,
>
> I have an HTTP server providing heavy algorithms. Sometimes, the clients
> closes the connection prematurely, before the end of computing.
>
> Note : Sometimes the client consuming these algorithms want to stop the
> process if the solution is not found before X minutes for example.
>
> This article :
> https://gianarb.it/blog/go-http-cleanup-http-connection-terminated
> shows how to use the "http.CloseNotifier" chan to receive the signal about
> the premature end of connection.
>
> *However*,
>
> The algorithm is made of several thousands of lines, called proceduraly,
> and sometimes even calling parallel computing on goroutines and recursive
> functions.
>
> It means that I should share the chan everywhere, to every functions or
> almost, insert a boilerplate of channel check frequently in the algorithm,
> and make an exit if needed.
>
> It seems to me pretty awful. Am I missing something ?
>
>
> Thanks a lot,
>
> --
> 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/ad1221ad-0ac6-4282-a708-20ab8d49fa5co%40googlegroups.com
> 
> .
>


-- 
Andrei Călin

-- 
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/CANnvmN4Bsy_ZhaYtEFtXV6wfudUb-QQdC00%2Bsk5Y1N5nD18T1A%40mail.gmail.com.

[go-nuts] [design] HTTP server serving heavy computing : Handle HTTP request closed prematurely

[Tamás Gulácsi]

Use request.Context - then you need to plant ctx everywhere, only.

-- 
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/828ac751-8f5f-4203-8456-fe7cced0b3a3o%40googlegroups.com.

[go-nuts] [design] HTTP server serving heavy computing : Handle HTTP request closed prematurely

[Thomas S]

Hello,

I have an HTTP server providing heavy algorithms. Sometimes, the clients 
closes the connection prematurely, before the end of computing.

Note : Sometimes the client consuming these algorithms want to stop the 
process if the solution is not found before X minutes for example.

This article : 
https://gianarb.it/blog/go-http-cleanup-http-connection-terminated
shows how to use the "http.CloseNotifier" chan to receive the signal about 
the premature end of connection.

*However*,

The algorithm is made of several thousands of lines, called proceduraly, 
and sometimes even calling parallel computing on goroutines and recursive 
functions.

It means that I should share the chan everywhere, to every functions or 
almost, insert a boilerplate of channel check frequently in the algorithm, 
and make an exit if needed.

It seems to me pretty awful. Am I missing something ?


Thanks a lot,

-- 
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/ad1221ad-0ac6-4282-a708-20ab8d49fa5co%40googlegroups.com.