[go-nuts] Re: when EOF returned from http client.Post, client can continue to be used ?
I did experiment but when using the same client I immediately got an EOF again. But that might also have been due to the rate-limiting. I started reading the source code of the http.Client and DefaultTransport but if any could advice good articles/books about the internals to get the most out of it, I would be very interested. On Monday, April 18, 2022 at 6:23:22 AM UTC+2 amits...@gmail.com wrote: > On Sunday, April 17, 2022 at 11:52:17 PM UTC+10 toon@gmail.com wrote: > >> It is not clear to me from the documentation whether I can continue to >> use an http.Client after a POST failed (due to the connection being closed >> ; In my case the connection closes probably due to rate-limiting). >> >> The documentation of the http.Transport does mention that, if a network >> error occurs, it will retry if the request is idempotent. Given I'm doing a >> basicPOST that is not the case for me. >> >> But the http.Client will reestablish the connection on the next call to >> Post(...) ? >> > > I believe you will see that's the case. Perhaps worth experimenting with > it? The reason is due to the underlying connection pooling behavior of the > DefaultTransport: https://go.dev/src/net/http/transport.go#L42: > " It establishes network connections as needed // and caches them for > reuse by subsequent calls" > > >> toon >> >> >> > -- 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/b28780a5-1e59-4562-95d5-b4ae964e2c4dn%40googlegroups.com.
[go-nuts] when EOF returned from http client.Post, client can continue to be used ?
It is not clear to me from the documentation whether I can continue to use an http.Client after a POST failed (due to the connection being closed ; In my case the connection closes probably due to rate-limiting). The documentation of the http.Transport does mention that, if a network error occurs, it will retry if the request is idempotent. Given I'm doing a basicPOST that is not the case for me. But the http.Client will reestablish the connection on the next call to Post(...) ? toon -- 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/c427f2a3-d5ae-4a1a-932a-18574713b1e0n%40googlegroups.com.
Re: [go-nuts] Re: autoremove unviolated precondition checks at compile time
> > > What you need is a prover that understands the facts holding up the > callers' stack and can statically detect tautologies in the calees > checks. Not trivial, but I believe it would be a ton of fun to write > ;-) Indeed, that is what I want to achieve. Are there any of these tools already? Maybe for other languages (that I can draw inspiration from) ? -- 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/b9e2e539-f99e-4d44-9157-723cd11a0c2cn%40googlegroups.com.
[go-nuts] Re: autoremove unviolated precondition checks at compile time
but that would enable or disable _all_ precondition checks.
What I am looking for is soth. smart enough that deduces that the
precondition checks in `mul` and `add` can be removed because of the
precondition check in `Muladd`.
On Thursday, March 31, 2022 at 5:26:44 AM UTC+2 Henry wrote:
> You will need a build tag for that.
>
> For example:
>
> In a separate file, define the build tag
> ```
> // +build debug
>
> package mypkg
>
> func init() {
>Debug = true
> }
> ```
> Then, in other files, use the tag
> ```
> package mypkg
>
> var Debug bool
>
> func DoWork() {
>if Debug {
> // perform validation
>}
> }
> ```
> When building with validation, call "go build -tags debug"
> On Thursday, March 31, 2022 at 1:40:07 AM UTC+7 toon@gmail.com wrote:
>
>> I like to check the preconditions of a function explicitly by means of
>> code (instead of only documenting them). Of course this incurs a
>> time-penalty.
>>
>> When being extremely cautious every function in a call-chain will always
>> check its preconditions. But for a function down in the call-chain, the
>> precondition checks of all its callers might already guarantee that its own
>> pre-condition checks will never be violated. And thus these checks down the
>> chain are unnecessary cpu cycles.
>>
>> Do there exist tools/methods to detect this and auto-remove these
>> precondition checks?
>>
>> For example:
>> the function Muladd below verifies that all arrays have the same length.
>> Muladd relies on two functions to perform the `mul` and the `add` and each
>> of these will also verify their respective preconditions explicitly. Given
>> these functions are not exported and given these functions are only called
>> by `muladd`, the compiler might be able to determine that the precondition
>> checks are guaranteed to be valid and can thus be removed.
>>
>> https://go.dev/play/p/92isKKx-vYx
>>
>> package main
>>
>> import "fmt"
>>
>> func main() {
>> x := []float64{1.0, 2.0, 3.0}
>> y := []float64{1.0, 2.0, 3.0}
>> z := []float64{1.0, 2.0, 3.0}
>> Muladd(x, y, z)
>> fmt.Printf("%+v", x)
>> }
>>
>> func Muladd(x []float64, y []float64, z []float64) error {
>> // check precondition (but unnecessary if only called by Muladd)
>> if len(x) != len(y) || len(x) != len(z) {
>> return fmt.Errorf("slices have different lengths %d vs %d vs %d",
>> len(x), len(y), len(z))
>> }
>> mul(x, y)
>> add(x, z)
>> return nil
>> }
>>
>> func mul(x []float64, y []float64) error {
>> // check precondition
>> if len(x) != len(y) {
>> return fmt.Errorf("slices have different lengths %d vs %d",
>> len(x), len(y))
>> }
>>
>> for i := range x {
>> x[i] *= y[i]
>> }
>> return nil
>> }
>>
>> func add(x []float64, y []float64) error {
>> // check precondition
>> if len(x) != len(y) {
>> return fmt.Errorf("slices have different lengths %d vs %d",
>> len(x), len(y))
>> }
>>
>> for i := range x {
>> x[i] += y[i]
>> }
>> return nil
>> }
>>
>
--
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/23966f0a-4ee9-4733-a4c0-ba1a4964d5f8n%40googlegroups.com.
[go-nuts] autoremove unviolated precondition checks at compile time
I like to check the preconditions of a function explicitly by means of code
(instead of only documenting them). Of course this incurs a time-penalty.
When being extremely cautious every function in a call-chain will always
check its preconditions. But for a function down in the call-chain, the
precondition checks of all its callers might already guarantee that its own
pre-condition checks will never be violated. And thus these checks down the
chain are unnecessary cpu cycles.
Do there exist tools/methods to detect this and auto-remove these
precondition checks?
For example:
the function Muladd below verifies that all arrays have the same length.
Muladd relies on two functions to perform the `mul` and the `add` and each
of these will also verify their respective preconditions explicitly. Given
these functions are not exported and given these functions are only called
by `muladd`, the compiler might be able to determine that the precondition
checks are guaranteed to be valid and can thus be removed.
https://go.dev/play/p/92isKKx-vYx
package main
import "fmt"
func main() {
x := []float64{1.0, 2.0, 3.0}
y := []float64{1.0, 2.0, 3.0}
z := []float64{1.0, 2.0, 3.0}
Muladd(x, y, z)
fmt.Printf("%+v", x)
}
func Muladd(x []float64, y []float64, z []float64) error {
// check precondition (but unnecessary if only called by Muladd)
if len(x) != len(y) || len(x) != len(z) {
return fmt.Errorf("slices have different lengths %d vs %d vs %d",
len(x), len(y), len(z))
}
mul(x, y)
add(x, z)
return nil
}
func mul(x []float64, y []float64) error {
// check precondition
if len(x) != len(y) {
return fmt.Errorf("slices have different lengths %d vs %d", len(x),
len(y))
}
for i := range x {
x[i] *= y[i]
}
return nil
}
func add(x []float64, y []float64) error {
// check precondition
if len(x) != len(y) {
return fmt.Errorf("slices have different lengths %d vs %d", len(x),
len(y))
}
for i := range x {
x[i] += y[i]
}
return nil
}
--
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/a1806c94-a605-4c8b-a78f-9e40c1a6098dn%40googlegroups.com.
Re: [go-nuts] Run a goroutine until a channel receives a message
Note from the gorilla websocket documentation ' *SetReadDeadline sets the
read deadline on the underlying network connection. After a read has timed
out, the websocket connection state is corrupt and all future reads will
return an error. A zero value for t means reads will not time out.*'
Thus IIUC once the timeout fired, you can not just continue the loop as
further reads from the ws will result in errors. However that is what the
OP intends to do if my understanding is correct.
A solution to me looks to spin up a goroutine that will read from the
websocket and will send what is read to a channel. Inside the loop the
select might than 'case' on the quit channel and the channel fed by the
ws.Read()
On Wednesday, January 13, 2021 at 12:15:57 PM UTC+1 be...@pferdewetten.de
wrote:
> Hi,
>
> if `ws.Read` returns after a reasonable timeout, you can perform a
> non-blocking receive on the quit channel to see if it has been
> closed/something has been sent to it:
>
> select {
> case <-quit:
> break
> default:
> // Nothing to do here
> }
>
> out, err := ws.Read()
> /* more stuff in the loop */
>
> Another approach would be to use a websocket library that supports
> passing a context to the Read method (not sure if any of those exists).
> For my usual go-to websocket library (github.com/gorilla/websocket), I
> usually set a read deadline on the connection in cases like this and
> more or less do the nonblocking read as above.
>
> On 13.01.21 12:10, Sankar wrote:
> > I have a function that must be executed as a go routine infinitely until
> > a message comes in a channel. For example:
> >
> > func readWebSocket(ws *websocket.socket, quit chan bool) {
> > for {
> > out, err = ws.Read()
> > log.Println(out, err)
> > }
> > }
> >
> > Now I call this above function as a goroutine from main such as:
> >
> > go readWebSocket(ws, quit)
> >
> > where I want the for loop to go on until the `quit` channel receives a
> > message. The "select" loop seem to work only on multiple channels and
> > not on a channel + some looping code.
> >
> > One alternative that I could think of was to create a second goroutine
> > (third if you include main) to which this readWebSocket can send the
> > output of "ws.Read" and the select loop can be run there with two
> > channels (the quit channel and the new channel which gets the "ws.Read"
> > output) but that would leak this reader go-routine infinitely or makes
> > the code more complex.
> >
> > How to handle this situation gracefully in go channels, where I want a
> > go routine to run until a channel gets a message ?
> >
> > Thanks.
> >
> > --
> > 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...@googlegroups.com
> > .
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/32f04de0-4684-40eb-9b1b-8a9a7ff80602n%40googlegroups.com
>
> > <
> https://groups.google.com/d/msgid/golang-nuts/32f04de0-4684-40eb-9b1b-8a9a7ff80602n%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
> --
> Gregor Best
> be...@pferdewetten.de
>
--
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/00c59c65-67a1-470d-8c86-095993e0dca6n%40googlegroups.com.
