Re: [go-nuts] how to handle push in http2 client?

[Eli Lindsey]

The x/net/http2 client doesn’t currently support receiving push promises - 
https://github.com/golang/net/blob/master/http2/transport.go#L2955

The tracking task is https://github.com/golang/go/issues/18594

-eli

> On Jan 26, 2023, at 11:29 AM, cheng dong  wrote:
> 
> says we do a server-push from http2 server, then how could we handle it in 
> golang code by http client in go 1.20rc3?
> 
> was there a HandlePush in early go version, if i did not forget
> 
> -- 
> 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/212cd7f2-abd0-4c0a-9b48-f141dfdf236dn%40googlegroups.com
>  
> .

-- 
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/239AD65C-FF9F-4299-87A6-5577825842E2%40siliconsprawl.com.

[go-nuts] Re: golang protobuf, struct copy problem

[cheng dong]

gob have bad performance compare to gogo-proto. in fact, every  reflection 
base encode/decode library do bad

On Thursday, May 21, 2020 at 12:03:18 AM UTC+8 Saied Seghatoleslami wrote:
Why not use gob encoding?  I am using it across nats and it is working 
fine.  The only workaround that I have had to do is to string encode the 
errors and convert them back to errors on the other side.


On Friday, May 8, 2020 at 2:56:22 PM UTC-4, cheng dong wrote:
i use protobuf to do rpc in golang . for every message XXX in proto,  i 
have to define a struct XXX in go, compute and then copy its field one by 
one to pb.XXX（because struct XXX have some field not in pb.XXX), when i 
have many struct XXX, it is very ineffective and very slow.

so how could i use a single struct both used for compute and marshal ?

-- 
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/897e08e4-1149-4a5e-83e3-23ee13435615n%40googlegroups.com.

[go-nuts] how to handle push in http2 client?

[cheng dong]

says we do a server-push from http2 server, then how could we handle it in 
golang code by http client in go 1.20rc3?

was there a HandlePush in early go version, if i did not forget

-- 
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/212cd7f2-abd0-4c0a-9b48-f141dfdf236dn%40googlegroups.com.

Re: [go-nuts] Variable Declaration inside infinite loop

[Ian Lance Taylor]

On Thu, Jan 26, 2023, 8:15 AM Roland Müller  wrote:

>
>
> Am Mittwoch, 25. Januar 2023 schrieb 'Jakob Borg' via golang-nuts <
> golang-nuts@googlegroups.com>:
> > On 25 Jan 2023, at 12:26, Shashwat  wrote:
> >>
> >> Is it safe to declare a variable inside an infinite loop ?
> >>
> >> for {
> >> a := 0
> >> a += 1
> >> }
> >>
> >> Won't this cause memory allocation in every iteration ?
> >>
> >> As the declared variables will be allocated memory in the stack and not
> heap memory, so garbage collector can't clear the allocated memory, and
> eventually process will be terminated, isn't it?
> >
> > No. Apart from compiler optimisations, consider that the variable goes
> out of scope at the end of each iteration.
> >
>
> In Java this may cause memory fragmentation when the amount of allocated
> memory varies and the variables use much memory.
>
> Dont know whether this may occur in Go too.
>

Not for a program like above, which will be entirely stack allocated.

Ian

>

-- 
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/CAOyqgcVw47a1dXJ__iaELtYFn%3Dmv6FZbkMno-QwNO%3Djw%3DO7b9Q%40mail.gmail.com.

Re: [go-nuts] %v display of nil map

[Andrew Athan]

I should have RTFMed, but even there, the nil display issue is not
highlighted :)  Thanks. It seemed odd that there wasn't already a way. It
might be good to highlight this feature in the right places. I'm not sure
if golangdocs.com is the official easy on-ramp for golang but if so, at
https://golangdocs.com/string-formatting-in-golang 's section 1.5 the
wording "print the Go-representation of the struct." could read "... the
struct, and explicitly show  valued slices and maps."; and the example
could show this case.

The same applies to the official documentation for the fmt package, which
states (in the comments of one example): " // The %#v form (the # is called
a "flag" in this context) shows the map in
// the Go source format. Maps are printed in a consistent order, sorted"
without reference to how nils are treated.

In addition, I would argue that the unadorned %v documentation should
mention that nil values are folded into the "empty" representation.

Anyway, as time allows I'll find the doc source and submit PRs implementing
the above suggestions.

Thank you for pointing this solution out.
Andrew

On Wed, Jan 25, 2023 at 12:05 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wed, 2023-01-25 at 07:21 -0800, Andrew Athan wrote:
> > I'm sure I'm not the first to say this, but here's my +1:
> >
> > It seems wrong to me that golang displays nil-valued reference types
> > as an empty instance of the type with no indication that the
> > reference is nil.
> >
> > E.g.
> > ```
> > var m map[string]string
> > fmt.Printf("%+v",m)
> > ```
> >
> > displays as "map[]"
> >
> > I think it would be better to display something like "map[]",
> > don't you?
> >
> > Motivation: While the nil map does act like a map[] for reads, it
> > does not act like one for writes, and debugging via prints can
> > therefore be confusing for new users.
> >
>
> For debugging, use %#v. https://go.dev/play/p/UlvaFg5Z_lB
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/6qKpr5_SXYA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6e278c5a183432315bb86e19b4c4f7794c9b56ab.camel%40kortschak.io
> .
>

-- 
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/CACUDngDFuV%3DP5XXTKW2OEqxr0Q72iDECWxbGsX5HktRg4XiQLA%40mail.gmail.com.

Re: [go-nuts] Variable Declaration inside infinite loop

[Robert Engels]

Java would no-op that entire loop since it does nothing that is externally 
visible. 

> On Jan 26, 2023, at 9:30 AM, Roland Müller  wrote:
> 
> 
> 
> Am Mittwoch, 25. Januar 2023 schrieb 'Jakob Borg' via golang-nuts 
> :
> > On 25 Jan 2023, at 12:26, Shashwat  wrote:
> >>
> >> Is it safe to declare a variable inside an infinite loop ?
> >>
> >> for {
> >> a := 0
> >> a += 1
> >> }
> >>
> >> Won't this cause memory allocation in every iteration ?
> >>
> >> As the declared variables will be allocated memory in the stack and not 
> >> heap memory, so garbage collector can't clear the allocated memory, and 
> >> eventually process will be terminated, isn't it?
> >
> > No. Apart from compiler optimisations, consider that the variable goes out 
> > of scope at the end of each iteration.
> >
> 
> In Java this may cause memory fragmentation when the amount of allocated 
> memory varies and the variables use much memory.
> 
> Dont know whether this may occur in Go too.
> 
> - Roland
> 
> > //jb
> >
> > --
> > 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/CE4EFF63-BD16-46F8-96EF-69000F7D9ACD%40kastelo.net.
> >
> -- 
> 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/CA%2B8p0G3nxAxWu0cNAJR_FWYQWvPdJHSP9v5X6VLhWFdh%2BxxenQ%40mail.gmail.com.

-- 
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/6467CA91-54F9-4856-99BB-D2B1F3E7A397%40ix.netcom.com.

[go-nuts] Re: Endless Running Goroutine Terminates Without Panic

[Brian Candler]

On Thursday, 26 January 2023 at 15:38:28 UTC Brian Candler wrote:
> As a goroutine may terminate if panic occurs

If that happens, it will crash the entire program (go isn't python :-)
https://go.dev/play/p/YD3lQ-xWe29

... although other goroutines may continue for a very short time 
afterwards.  I did see the above link generate the following output a 
couple of times:

Hello, 世界
panic: foo

goroutine 6 [running]:
main.main.func1()
/tmp/sandbox319329598/prog.go:13 +0x65
created by main.main
/tmp/sandbox319329598/prog.go:11 +0x76

Program exited.

-- 
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/a2580f73-9e57-459d-8b13-daf2f89dc182n%40googlegroups.com.

[go-nuts] Re: Endless Running Goroutine Terminates Without Panic

[Brian Candler]

> As a goroutine may terminate if panic occurs

If that happens, it will crash the entire program (go isn't python :-)
https://go.dev/play/p/YD3lQ-xWe29

> I used recover() to log the error and the monitoring thread is 
re-created. But this doesn't help either. I noticed that the goroutine has 
been terminated but error hasn't been logged.

How are you sure then, that the goroutine has terminated, not that it's 
just stuck?

In any case, you shouldn't attempt to recover from a system-related panic 
(e.g. out of memory).  The system will be in an invalid state; better let 
it crash and be restarted by some external supervisor.  You can recover 
from an explicit panic() raised in your code, which is sometimes useful 
when unwinding the stack many levels, e.g. to terminate some deeply-nested 
recursive function, but that's something else.

> Each sensor's state is maintained in sync.Map. The map maintains a 
pointer to the state.

Whilst sync.Map protects against concurrent read/write access to the map 
itself, it doesn't protect against how you use that data.  If you retrieve 
a pointer, and then read or write via that pointer from different 
goroutines, then you'll still need to protect those accesses with a mutex.  
It looks like you're doing this in the reading loop; we don't see the code 
which writes to the state.

However, the go maxim is "share memory by communicating 
".  Could you arrange it so that your 
data collection process sends data down a channel, instead of updating 
shared memory? 

On Thursday, 26 January 2023 at 15:03:14 UTC qa80...@gmail.com wrote:

> I need to monitor the status of the N sensors and log it. I am creating a 
> separate goroutine for each sensor which fetches the state and logs it at 
> regular intervals. For each goroutine, a channel is created to read the 
> termination signal. Each sensor's state is maintained in sync.Map. The map 
> maintains a pointer to the state. Apart from monitoring goroutines, there 
> are processing goroutines that update the sensor's state.
>
> In my current implementation, the goroutines are able to log the status at 
> regular intervals. But after a few days, some goroutines stop logging the 
> status. But the processing goroutines are able to update the status. 
>
> As a goroutine may terminate if panic occurs, I used recover() to log the 
> error and the monitoring thread is re-created. But this doesn't help 
> either. I noticed that the goroutine has been terminated but error hasn't 
> been logged.
>
> I suspect that because of memory leak, the goroutine might be terminated.
>
> Please find attached sample code.
>
>
> It will be helpful if someone explains this abnormal behavior and provides 
> possible solutions.
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e9da5e39-c664-4c52-aa4f-fded392b96f0n%40googlegroups.com.

Re: [go-nuts] Variable Declaration inside infinite loop

[Roland Müller]

Am Mittwoch, 25. Januar 2023 schrieb 'Jakob Borg' via golang-nuts <
golang-nuts@googlegroups.com>:
> On 25 Jan 2023, at 12:26, Shashwat  wrote:
>>
>> Is it safe to declare a variable inside an infinite loop ?
>>
>> for {
>> a := 0
>> a += 1
>> }
>>
>> Won't this cause memory allocation in every iteration ?
>>
>> As the declared variables will be allocated memory in the stack and not
heap memory, so garbage collector can't clear the allocated memory, and
eventually process will be terminated, isn't it?
>
> No. Apart from compiler optimisations, consider that the variable goes
out of scope at the end of each iteration.
>

In Java this may cause memory fragmentation when the amount of allocated
memory varies and the variables use much memory.

Dont know whether this may occur in Go too.

- Roland

> //jb
>
> --
> 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/CE4EFF63-BD16-46F8-96EF-69000F7D9ACD%40kastelo.net
.
>

-- 
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/CA%2B8p0G3nxAxWu0cNAJR_FWYQWvPdJHSP9v5X6VLhWFdh%2BxxenQ%40mail.gmail.com.

[go-nuts] Endless Running Goroutine Terminates Without Panic

[Shashwat]

I need to monitor the status of the N sensors and log it. I am creating a 
separate goroutine for each sensor which fetches the state and logs it at 
regular intervals. For each goroutine, a channel is created to read the 
termination signal. Each sensor's state is maintained in sync.Map. The map 
maintains a pointer to the state. Apart from monitoring goroutines, there 
are processing goroutines that update the sensor's state.

In my current implementation, the goroutines are able to log the status at 
regular intervals. But after a few days, some goroutines stop logging the 
status. But the processing goroutines are able to update the status. 

As a goroutine may terminate if panic occurs, I used recover() to log the 
error and the monitoring thread is re-created. But this doesn't help 
either. I noticed that the goroutine has been terminated but error hasn't 
been logged.

I suspect that because of memory leak, the goroutine might be terminated.

Please find attached sample code.


It will be helpful if someone explains this abnormal behavior and provides 
possible solutions.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0936fbc8-9f47-45ca-9e93-a6f6590f3adcn%40googlegroups.com.
// sensor state struct
type sensorState struct {
a float64
b int
lock sync.Mutex
ch   chan int
}

type curStatus struct {
a float64
b int
...
}

// log struct
type stateLog struct {
state curStatus
timestamp int64
method string
}

// stateMap maintains state of different sensors
var stateMap sync.Map
stateMap.Store("Sensor-A", &sensorState{
  a : 0,
  b : 0,
  lock : sync.Mutex{},
  ch : make(chan int)
   })


func ChargerMonitoringThreadV2(sensorId string) {

isStateLocked := false
sensorStatus := curStatus{}

sessionState, _ := stateMap.Load(sensorId)
state, _ := sessionState.(*sensorState)

defer func() {
if er := recover(); er != nil {
fmt.Printf("ERROR: [sensorId:%s][ChargerMonitoringThreadV2] 
Recovered from - %v", sensorId, er)
fmt.Printf("ERROR: [sensorId:%s][ChargerMonitoringThreadV2] 
stacktrace from panic:\n%s", sensorId, string(debug.Stack()))

if isStateLocked {
fmt.Printf("INFO: [sensorId:%s][ChargerMonitoringThreadV2] 
Released  lock\n", sensorId)
state.lock.Unlock()
isStateLocked = false
}

go ChargerMonitoringThreadV2(sensorId)
logging.ReportException(fmt.Errorf("%v\n%s", er, 
string(debug.Stack( // log error
return
}
}()

for {
select {
   
case <-state.ch:
fmt.Printf("INFO: [sensorId:%s][monitoringThread] Terminating 
monitoring thread...\n", sensorId)
return
   
default:

curTS := time.Now().UnixMilli()

state.lock.Lock()
isSessionStateLocked = true

sensorStatus.a = state.a

state.lock.Unlock()
isSessionStateLocked = false

insertLog(&stateLog{
state: sensorStatus,
timestamp: curTS,
method:"monitoringThread",
})

time.Sleep(60 * time.Second)
}
}
}