Re: [go-nuts] Re: A better way of events notification from cgo to go side

[Ian Lance Taylor]

On Sun, Sep 17, 2017 at 10:10 PM, Sokolov Yura  wrote:
>
> Isn't there a way to pass Go callback to Cgo? In this callback you may do 
> anything.

You can't pass a simple callback, but you can have your C code call a
Go function whenever some event occurs.  Start a new thread in C, have
it wait, and have it call Go when appropriate.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] cannot assign 1 values to 2 variables [simple error handling]

[Ian Lance Taylor]

You are trying to assign the result of loadPage to two variables, but
loadPage only returns one result.

In the "here is OK" section you are assigning the result of ioutil.ReadFile
to two variables.  That is OK because ioutil.ReadFile returns two results.
You can see the definition of ioutil.ReadFile at
https://golang.org/src/io/ioutil/ioutil.go#L45 .

Ian



On Sun, Sep 17, 2017 at 8:00 PM, Ângelo Chida  wrote:

> Hi, I'm new in Golang but I'm PHP StackDev since 10 years ago
> I'm following this tutorial https://golang.org/doc/articles/wiki/ on how
> to build a web app, but I'm stuck on some error and can't find anywhere a
> solution. Please help
> Take a look at the image
> My go version is 1.9
>
>
> *sorry
> for poor english, it is not my native language
> 
>
>
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] redirecting templates from revel

[Vikram Rawat]

I am not able to understand how can I redirect on the click of some text or 
button a user to a different page.

I went to entire documentation but I was not able to understand it. Like 
revel page say. 

---put this HTML in index page--







 create this HTML as hello.html page 

{{set . "title" "Home"}}
{{template "header.html" .}}

Hello {{.myName}}
Back to form

{{template "footer.html" .}}


---put this in app.go ---

func (c App) hello1(myName string) revel.Result {
   return c.Render(myName)
}

---

---




I tried to use the same code to send the user to another html page. say 
abc.html in app folder. 

How can I do that. Please help me. i don't think it is hard for you but for me 
it took my entire weekend.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A better way of events notification from cgo to go side

[Sokolov Yura]

And I agree that socketpair and regular read from will also do the job.
https://github.com/prep/socketpair/blob/master/socketpair.go

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A better way of events notification from cgo to go side

[Sokolov Yura]

Isn't there a way to pass Go callback to Cgo? In this callback you may do 
anything.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] cannot assign 1 values to 2 variables [simple error handling]

[Ângelo Chida]

Hi, I'm new in Golang but I'm PHP StackDev since 10 years ago
I'm following this tutorial https://golang.org/doc/articles/wiki/ on how to 
build a web app, but I'm stuck on some error and can't find anywhere a 
solution. Please help
Take a look at the image
My go version is 1.9

*sorry
 
for poor english, it is not my native language 




-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: how to sort http.Header by ourselves

[Chengbin Du]

thank you for your reply.

I have to do this, so i forked the http package, and implemented header 
fields order feature.  :)

thanks a lot!

在 2017年9月15日星期五 UTC+8下午4:07:35，Dave Cheney写道：
>
> The author replied to their own post saying that header order was probably 
> not the issue, and give the HTTP RFCs define headers to be an unordered set 
> not an array, I'm inclined to agree.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Do you check in vendor packages?

[gurpartap]

Create a separate repo for vendor directory. Set it to "auto check-in" in 
main repo's git push hook. Done.

Moreover, with submodule hash info included in main repo commits, the 
vendor repo can map better on checkouts. You could this skip submodules 
mapping if you don't mind rewinding manually when needed (which isn't 
often, is it?).

Regards,
Gurpartap Singh

On Saturday, September 16, 2017 at 12:21:38 AM UTC+5:30, Will Faught wrote:
>
> Kevin, Henrik:
>
> Thanks for replying!
>
> Have you ever had to check in very large dependencies? Would you still do 
> it if just one dep added 30 MB to your 10 MB repo? What if the size of your 
> code is dwarfed by the size of your deps 10:1? I'm curious how far people 
> are willing to go to check in their deps—do they check in regardless of 
> size? Or is a hybrid approach the best, where you check in all but the very 
> large deps?
>
> I've been wondering whether the dep size cost is mostly a one-time, 
> up-front cost when you first check it in, and updates thereafter are 
> relatively very small, such that in the long run the size cost is maybe at 
> most 2x the initial size, which is basically a fixed, constant cost 
> compared to the ongoing size growth of your overall repo in the long run.
>
> On Thu, Sep 14, 2017 at 11:54 PM, Henrik Johansson  > wrote:
>
>> I always check in. It is super nice to not have to download separately 
>> and have one transitive dep destroy everything when you need it the least. 
>>
>> On Fri, 15 Sep 2017, 02:37 Kevin Malachowski > > wrote:
>>
>>> I generally vote for checking in, or at least ensuring that /something/ 
>>> has an in-house copy of all dependencies. The worst thing that can happen 
>>> is someone deleting their repository and having your project being super 
>>> broken.
>>>
>>> (See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)
>>>
>>> --
>>> 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 .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> 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/EapE_L8TCdA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[Dave Cheney]

What is the problem you are trying to solve?

Said another way. If you can confirm (or disprove, whichever suits) that Go 
uses __vdso_clock_gettime_sym with CLOCK_MONOTONIC, what would you do with 
that information?

On Monday, 18 September 2017 09:08:41 UTC+10, Ronald wrote:
>
> In `go1.9 @ linux 3.10.0-327.el7.x86_64`, the call __vdso_clock_gettime_sym 
> is 
> completely in userspace, and does not involve any syscall in the kernel, 
> and that is 
> the reason __vdso_clock_gettime_sym with CLOCK_MONOTONIC is so fast. ( In 
> C, 
> the perf of __vdso_clock_gettime_sym is about 14,000,000 op/s, it drops 
> to nearly 
> 7,000,000 op/s in golang's implementation. )
>
> On Mon, Sep 18, 2017 at 5:28 AM, David Collier-Brown  > wrote:
>
>> You may need to look and see what __vdso_clock_gettime_sym calls at the 
>> system-call level, and compare that with the system calls reported by 
>> strace from your executable. 
>>
>> I assume you want some particular thing that __vdso_clock_gettime_sym 
>> does: try asking the folks about *that*, as they may already know.
>>
>> -- 
>> 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A better way of events notification from cgo to go side

[Remus Clearwater]

There maybe a 4th method is to use something like eventfd/socketpair 
between go and cgo sides,
but it still has a long-blocking call in syscall.Read unless we could add 
supports of epoll-eventfd/socketpair 
to the go runtime.

On Monday, September 18, 2017 at 6:43:03 AM UTC+8, Remus Clearwater wrote:
>
> In the 3rd method `long wait`, if the cgo could emit some dummy 
> "heartbeat" events 
> notification periodically (e.g., 10ms), that would be nearly the same as 
> `C.sema_timedwait` 
> although there will be a little overhead.
>
> On Monday, September 18, 2017 at 6:28:11 AM UTC+8, Remus Clearwater wrote:
>>
>> But according to the man sem_timedwait(3), the abs_timeout is subjected 
>> to the 
>> `discontinuous jumps in the system time (e.g., if the system 
>> administrator manually 
>> changes the clock)`, and `adjtime(3) & NTP`.
>>
>> Imaging the system administrator manually put the clock say 10 seconds 
>> behind,
>> thus the `C.sema_timedwait ` is just nearly the same as the method 3 
>> `long wait`.
>>
>> On Monday, September 18, 2017 at 4:41:17 AM UTC+8, Tamás Gulácsi wrote:
>>>
>>> C.sema_timedwait ?
>>> No latency, and with a few seconds for timeout, not too long.
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[Sen Han]

Which in this case, the `strace` cannot trace a single syscall that
involves the time.

On Mon, Sep 18, 2017 at 7:08 AM, Sen Han  wrote:

> In `go1.9 @ linux 3.10.0-327.el7.x86_64`, the call __vdso_clock_gettime_sym
> is
> completely in userspace, and does not involve any syscall in the kernel,
> and that is
> the reason __vdso_clock_gettime_sym with CLOCK_MONOTONIC is so fast. ( In
> C,
> the perf of __vdso_clock_gettime_sym is about 14,000,000 op/s, it drops
> to nearly
> 7,000,000 op/s in golang's implementation. )
>
> On Mon, Sep 18, 2017 at 5:28 AM, David Collier-Brown 
> wrote:
>
>> You may need to look and see what __vdso_clock_gettime_sym calls at the
>> system-call level, and compare that with the system calls reported by
>> strace from your executable.
>>
>> I assume you want some particular thing that __vdso_clock_gettime_sym
>> does: try asking the folks about *that*, as they may already know.
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[Sen Han]

In `go1.9 @ linux 3.10.0-327.el7.x86_64`, the call __vdso_clock_gettime_sym
is
completely in userspace, and does not involve any syscall in the kernel,
and that is
the reason __vdso_clock_gettime_sym with CLOCK_MONOTONIC is so fast. ( In
C,
the perf of __vdso_clock_gettime_sym is about 14,000,000 op/s, it drops to
nearly
7,000,000 op/s in golang's implementation. )

On Mon, Sep 18, 2017 at 5:28 AM, David Collier-Brown 
wrote:

> You may need to look and see what __vdso_clock_gettime_sym calls at the
> system-call level, and compare that with the system calls reported by
> strace from your executable.
>
> I assume you want some particular thing that __vdso_clock_gettime_sym
> does: try asking the folks about *that*, as they may already know.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A better way of events notification from cgo to go side

[Remus Clearwater]

In the 3rd method `long wait`, if the cgo could emit some dummy "heartbeat" 
events 
notification periodically (e.g., 10ms), that would be nearly the same as 
`C.sema_timedwait` 
although there will be a little overhead.

On Monday, September 18, 2017 at 6:28:11 AM UTC+8, Remus Clearwater wrote:
>
> But according to the man sem_timedwait(3), the abs_timeout is subjected to 
> the 
> `discontinuous jumps in the system time (e.g., if the system administrator 
> manually 
> changes the clock)`, and `adjtime(3) & NTP`.
>
> Imaging the system administrator manually put the clock say 10 seconds 
> behind,
> thus the `C.sema_timedwait ` is just nearly the same as the method 3 
> `long wait`.
>
> On Monday, September 18, 2017 at 4:41:17 AM UTC+8, Tamás Gulácsi wrote:
>>
>> C.sema_timedwait ?
>> No latency, and with a few seconds for timeout, not too long.
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A better way of events notification from cgo to go side

[Remus Clearwater]

But according to the man sem_timedwait(3), the abs_timeout is subjected to 
the 
`discontinuous jumps in the system time (e.g., if the system administrator 
manually 
changes the clock)`, and `adjtime(3) & NTP`.

Imaging the system administrator manually put the clock say 10 seconds 
behind,
thus the `C.sema_timedwait ` is just nearly the same as the method 3 `long 
wait`.

On Monday, September 18, 2017 at 4:41:17 AM UTC+8, Tamás Gulácsi wrote:
>
> C.sema_timedwait ?
> No latency, and with a few seconds for timeout, not too long.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[David Collier-Brown]

You may need to look and see what __vdso_clock_gettime_sym calls at the 
system-call level, and compare that with the system calls reported by 
strace from your executable. 

I assume you want some particular thing that __vdso_clock_gettime_sym does: 
try asking the folks about *that*, as they may already know.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Create a file and control whether to overwrite or not

[Tamás Gulácsi]

Why the double open?
mode:=os.O_RDWR...
if overwrite { mode |= os.O_TRUNC}
os.OpenFile(name, mode)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] A better way of events notification from cgo to go side

[Tamás Gulácsi]

C.sema_timedwait ?
No latency, and with a few seconds for timeout, not too long.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Create a file and control whether to overwrite or not

[DrGo]

Hello,
The default behaviour of os.Create is to truncate the file if already 
exists. I wrote the code below to control whether the file should be 
overwritten or not (possibly based on user wishes). Seems to work on MacOS.
Do you think this code will work on Windows and Linux? Do you see any 
subtle issues with races etc.

Thanks,

func CreateFile(fileName string, overWrite bool) (out *os.File, err error) {
out, err = os.OpenFile(fileName, os.O_RDWR|os.O_CREATE|os.O_EXCL, 0666)
switch {
case os.IsExist(err): //failed because file already exists
if overWrite {
return os.OpenFile(fileName, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 
0666) //overwrite it
}
return nil, fmt.Errorf("file %s already exists", fileName)
default: //no errors or errors other than file exists
return out, err
}
}

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] A better way of events notification from cgo to go side

[Remus Clearwater]

Hi, I wonder if there has a small cost, little latency and high efficient 
solution 
of event notification from cgo to go side.

Here is 3 ways as far as I know:

1. Poll

go func() {
for {
// fast ret from cgo 
ret := C.sema_try_wait()
if new events {
do_new_event_tasks()
}else{
time.Sleep(time.Millisecond * 250)
}
}
}()

Disadvantage：

Would be some overhead and constant latency.

2. Long wait

go func() {
for {
// maybe blocking at cgo side arbitrarily long time
ret := C.sema_wait()
do_new_event_tasks()
}
}()

Disadvantage：

As been discussed in issue 12416 
:

Q: What kind of errors will be returned when a C function takes too long? 
>
What is the story with regards to read(2) and blocking devices? (by taruti)

 

A: In the default mode, nothing will happen if a C function takes too long, 

except that your program might eventually run out of memory because the GC 

can't run (that won't happen with 1.6 but it might happen in future 
> releases). 

In the checking mode, you will get a panic. If you want to call a C 
> function 

that does a read on a device that blocks arbitrarily long, you should read 
> the 

data into a buffer allocated by C. We will make the syscall.Read function 
> do the 

right thing on a long-blocking read, whatever that turns out to be.

So, if one cgo call takes too long is not recommend, we still need a cgo 
> notify to 

go mechanism. (by ianlancetaylor)


So, if the cgo call takes too long to return is not recommend, 
we still need another cgo 
notify to go mechanism. 

3. Raise a signal

c := make(chan os.Signal, 1)
signal.Notify(c, SignalUsr1)
for{
// cgo just raise SignalUsr1 to itself when 
// it want to notify go side
s := <-c
do_new_event_tasks()
}

Disadvantage：

A little wierd, and when there is about 10 new events to 
notify per seconds, the overhead would be huge.

Is there some much better methods? 

Thanks a lot.

-- Remus

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: context cancellation flake

[Jesper Louis Andersen]

On Sun, Sep 17, 2017 at 12:46 PM Steven Lee  wrote:

> Thank you Silviu, that seems to work.
>
> Do you know exactly why it flakes? what is racing? just for me to have an
> understanding of why this happens
>
>
It is somewhat common to use the TCP window as a feedback mechanism to the
server. If you can't process the body streamed to you fast enough, then the
TCP window will fill and the server will stop sending. The
alternative--empty the buffer in the kernel at the earliest--can lead to
memory spikes in your program if you request large bodies in a short amount
of time. In my experience, you should aim for sustained memory load rather
than spiky memory load if you can.

What likely happens is that the http client ends up in a state where it
knows the status code of the request, but it hasn't yet read all of the
body. Then the cancel arrives on the context. In this case, we abort the
body read. It can be a half read, or perhaps we have not yet pulled
anything from the body into the Go process from the kernels buffer.

One reason for this behavior may be that many HTTP requests have no body,
so you end up with code which is more complex if you need to cater for this
and the context at the same time.

Silviu already wrote what I would do to alleviate the problem.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Latency profiling

[Sen Han]

(Sorry for the noise.)

Hi Juliusz, this tool go-tool-trace-greediest-goroutines
would be
helpful.(
may also refer the issue 20792 )

All best

-- Sen

On Sun, Sep 17, 2017 at 9:12 PM, Juliusz Chroboczek  wrote:

> Hi,
>
> I've got a CPU-bound function that is not called very frequently, and
> hence doesn't appear prominently in the CPU profile, but I'm guessing
> that it takes a significant time to run (on the order of tens of
> milliseconds), and hence increases the latency of the calling goroutine.
>
> I don't see anything in pprof to give the average and maximum time spent
> in a given function, let alone to get the list of functions that have
> the highest maximum CPU time per invocation.  Not a big deal, I'm going
> to instrument the function manually, but I'm wondering if I'm missing
> something.
>
> Thanks,
>
> -- Juliusz
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: context cancellation flake

[silviucapota]

Steven, no problem. For more details have a look at
a) This talk by Sameer Ajmani: https://vimeo.com/115309491
b) Francesc Campoy's series of 
videos: https://github.com/campoy/justforfunc  
In the Readme, you'll find likes to episodes 9 and 10, which deal with 
explaning and implementing the context package.

But, to answer your question very quickly: the purpose for the cancel 
function is to voluntarily signal to the rest of your program that one 
particular flow of operations (determined by you, when you design your 
application) is over.
You are calling it as a courtesy to some other go routines inside your 
program which may depend on, or act upon the same operation.

In your case, you want to read from that external endpoint some json or xml 
values, right ? 
As far as you're concerned, the real "finish line" of that particular flow 
is after ioutil.ReadAll, not the ctxhttp.Do method, correct ? That's why 
you need to make sure you call cancel() after that one, not too early.

Due to the fact that you are calling cancel too early, as Tamás pointed 
out, you are not guaranteed to receive the response body, because the http 
internal mechanisms are not synchronous and are complex enough.
If you have some good hours to spend (take your time, to understand it 
correctly), dig into the source code directly. Start with 
https://github.com/golang/net/blob/master/context/ctxhttp/ctxhttp.go#L26
that will take you into:
https://github.com/golang/go/blob/master/src/net/http/client.go#L490
and so forth...


On Sunday, 17 September 2017 06:46:00 UTC-4, Steven Lee wrote:
>
> Thank you Silviu, that seems to work.
>
> Do you know exactly why it flakes? what is racing? just for me to have an 
> understanding of why this happens
>
> On Sunday, 17 September 2017 01:19:35 UTC+1, Silviu Capota Mera wrote:
>>
>> Hi Steven,
>>
>> In case it's still unclear, you need to wrap both the "do request" + 
>> "read body" inside the same cancellation context. The "defer cancel" should 
>> encompass both of them, sort of atomically, so the idea is to take it out 
>> of your fetch, one level up.
>>
>> https://play.golang.org/p/trMP7Q-maT
>>
>> Cheers,
>> silviu
>>
>> On Saturday, 16 September 2017 16:16:05 UTC-4, Steven Lee wrote:
>>>
>>> I guess thats plausible
>>>
>>> Ive tried to find the code in the library that sets the body if a 
>>> context is cancelled but cant, I understand how to fix the code just 
>>> struggling to understand the mechanics and especially why it flakes :(
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Latency profiling

[Juliusz Chroboczek]

Hi,

I've got a CPU-bound function that is not called very frequently, and
hence doesn't appear prominently in the CPU profile, but I'm guessing
that it takes a significant time to run (on the order of tens of
milliseconds), and hence increases the latency of the calling goroutine.

I don't see anything in pprof to give the average and maximum time spent
in a given function, let alone to get the list of functions that have
the highest maximum CPU time per invocation.  Not a big deal, I'm going
to instrument the function manually, but I'm wondering if I'm missing
something.

Thanks,

-- Juliusz

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: context cancellation flake

[Steven Lee]

Thank you Silviu, that seems to work.

Do you know exactly why it flakes? what is racing? just for me to have an 
understanding of why this happens

On Sunday, 17 September 2017 01:19:35 UTC+1, Silviu Capota Mera wrote:
>
> Hi Steven,
>
> In case it's still unclear, you need to wrap both the "do request" + "read 
> body" inside the same cancellation context. The "defer cancel" should 
> encompass both of them, sort of atomically, so the idea is to take it out 
> of your fetch, one level up.
>
> https://play.golang.org/p/trMP7Q-maT
>
> Cheers,
> silviu
>
> On Saturday, 16 September 2017 16:16:05 UTC-4, Steven Lee wrote:
>>
>> I guess thats plausible
>>
>> Ive tried to find the code in the library that sets the body if a context 
>> is cancelled but cant, I understand how to fix the code just struggling to 
>> understand the mechanics and especially why it flakes :(
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] Learn Go by Writing REST APIs - Free Workshop (Tel Aviv)

[Miki Tebeka]

Hi,

We'll be doing an introductory "hands on" workshop for people who are 
interested in learning Go.
We'll learn go by writing a REST API server.

Limited availability, register 
at 
https://www.eventbrite.com/e/learn-go-by-writing-rest-apis-tickets-37870497678

Happy hacking,
--
Miki 

-- 
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.
For more options, visit https://groups.google.com/d/optout.