Re: [go-nuts] How to set a callback for cgo ?

[astone . chou]

sorry for late reply. thanks very much. it got the key.

在 2019年1月11日星期五 UTC+8下午10:09:17，Jan Mercl写道：
>
>
> On Fri, Jan 11, 2019 at 2:49 PM > wrote:
>
> > I get the file 'exit0', but didn't get the file 'exit1'.
>
> As far as I can tell, it works as expected. Exit handlers are called when 
> libc's 'exit' is invoked. I don't think that the Go runtime does that. The 
> proper way to handle process exiting is to handle it in its parent process.
>
> -- 
>
> -j
>

-- 
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] what is the use of context in golang RESTful apis?

[robert engels]

Context is in no way shape or form a crutch. It is a required element of any 
multi-user or distributed system. You may call it something else, but in the 
end it is a “context”.

> On Jan 16, 2019, at 7:29 PM, Space A.  wrote:
> 
> Problems are fine. And developer should be able to take care of them. That's 
> what he does. Context is basically a crutch. So are you proposing to make a 
> crutch a language construct?
> 
> 
> четверг, 17 января 2019 г., 0:43:58 UTC+3 пользователь robert engels написал:
> I agree with all of those assessments. That’s why I think the “context” needs 
> to be moved into a language construct. Then the developer is insulated from 
> most (all) of these problems - that is the “current context” propagates 
> unless specifically told not to when creating the Go routine. In almost all 
> cases the context is a single reference so it should be cheap to propagate. 
> 
> If the “context” was a higher level standardized concept, then the “values” 
> could be typed, so all of the benefits of the Java way - transactions, 
> logging, “current user”, etc. can all be addressed in a type-safe manner. 
> 
> I’ve stated a few times that a Go routines lack of context (name, purpose, 
> etc) is a huge problem. It really limits the ability to write very high 
> performance applications (pinning routines to cores, groups of routines to 
> CPU’s, marking some routines as “delay GC”, etc.). 
> 
> > On Jan 16, 2019, at 3:33 PM, Ian Lance Taylor golang.org 
> > > wrote: 
> > 
> >> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels ix.netcom.com 
> >> > wrote: 
> >> 
> >> 
> >> I don’t see the complexity nor the real difference between Go routines and 
> >> Threads. In Java TLS is not passed to new threads you need to be explicit. 
> >> The ThreadLocal doesn’t allow  access to other threads locals even with 
> >> thread groups, etc. As far as I understand Go has no concept of parent Go 
> >> routine - at least not exposed - so I don’t see the issue. 
> > 
> > The difference is that in Java creating a new thread is a relatively 
> > heavyweight operation.  It's not hard, but it's not routine.  It's 
> > reasonable that when creating a new thread you consider how to handle 
> > any thread local variables.  In particular everybody understands that 
> > the new thread will not have access to any of the thread local 
> > variables of the parent thread. 
> > 
> > In Go new goroutines are started frequently and casually.  For 
> > example, it's routine for people to change a loop computing a list of 
> > values into a loop that starts a goroutine for each computation.  If 
> > we are using a thread-local context.Context to cancel a goroutine, 
> > then one would naturally expect all those goroutines to inherit that 
> > Context value, so that they too will be stopped.  If they don't 
> > inherit it, then we need some extra mechanism to set the thread-local 
> > Context, and we need to remember to do that.  If they do inherit it, 
> > then we need to think about the cases where they shouldn't inherit it. 
> > Either way, the operation is sometimes implicit and sometimes 
> > explicit.  That is confusing. 
> > 
> > In Java it's not confusing to always make thread-local handling 
> > explicit.  In Go that would be frustrating and awkward. 
> > 
> > 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 
> .

-- 
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] what is the use of context in golang RESTful apis?

[Space A.]

Problems are fine. And developer should be able to take care of them. 
That's what he does. Context is basically a crutch. So are you proposing to 
make a crutch a language construct?


четверг, 17 января 2019 г., 0:43:58 UTC+3 пользователь robert engels 
написал:
>
> I agree with all of those assessments. That’s why I think the “context” 
> needs to be moved into a language construct. Then the developer is 
> insulated from most (all) of these problems - that is the “current context” 
> propagates unless specifically told not to when creating the Go routine. In 
> almost all cases the context is a single reference so it should be cheap to 
> propagate. 
>
> If the “context” was a higher level standardized concept, then the 
> “values” could be typed, so all of the benefits of the Java way - 
> transactions, logging, “current user”, etc. can all be addressed in a 
> type-safe manner. 
>
> I’ve stated a few times that a Go routines lack of context (name, purpose, 
> etc) is a huge problem. It really limits the ability to write very high 
> performance applications (pinning routines to cores, groups of routines to 
> CPU’s, marking some routines as “delay GC”, etc.). 
>
> > On Jan 16, 2019, at 3:33 PM, Ian Lance Taylor  > wrote: 
> > 
> >> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  > wrote: 
> >> 
> >> 
> >> I don’t see the complexity nor the real difference between Go routines 
> and Threads. In Java TLS is not passed to new threads you need to be 
> explicit. The ThreadLocal doesn’t allow  access to other threads locals 
> even with thread groups, etc. As far as I understand Go has no concept of 
> parent Go routine - at least not exposed - so I don’t see the issue. 
> > 
> > The difference is that in Java creating a new thread is a relatively 
> > heavyweight operation.  It's not hard, but it's not routine.  It's 
> > reasonable that when creating a new thread you consider how to handle 
> > any thread local variables.  In particular everybody understands that 
> > the new thread will not have access to any of the thread local 
> > variables of the parent thread. 
> > 
> > In Go new goroutines are started frequently and casually.  For 
> > example, it's routine for people to change a loop computing a list of 
> > values into a loop that starts a goroutine for each computation.  If 
> > we are using a thread-local context.Context to cancel a goroutine, 
> > then one would naturally expect all those goroutines to inherit that 
> > Context value, so that they too will be stopped.  If they don't 
> > inherit it, then we need some extra mechanism to set the thread-local 
> > Context, and we need to remember to do that.  If they do inherit it, 
> > then we need to think about the cases where they shouldn't inherit it. 
> > Either way, the operation is sometimes implicit and sometimes 
> > explicit.  That is confusing. 
> > 
> > In Java it's not confusing to always make thread-local handling 
> > explicit.  In Go that would be frustrating and awkward. 
> > 
> > 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] what is the use of context in golang RESTful apis?

[robert engels]

I agree with all of those assessments. That’s why I think the “context” needs 
to be moved into a language construct. Then the developer is insulated from 
most (all) of these problems - that is the “current context” propagates unless 
specifically told not to when creating the Go routine. In almost all cases the 
context is a single reference so it should be cheap to propagate.

If the “context” was a higher level standardized concept, then the “values” 
could be typed, so all of the benefits of the Java way - transactions, logging, 
“current user”, etc. can all be addressed in a type-safe manner.

I’ve stated a few times that a Go routines lack of context (name, purpose, etc) 
is a huge problem. It really limits the ability to write very high performance 
applications (pinning routines to cores, groups of routines to CPU’s, marking 
some routines as “delay GC”, etc.).

> On Jan 16, 2019, at 3:33 PM, Ian Lance Taylor  wrote:
> 
>> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  wrote:
>> 
>> 
>> I don’t see the complexity nor the real difference between Go routines and 
>> Threads. In Java TLS is not passed to new threads you need to be explicit. 
>> The ThreadLocal doesn’t allow  access to other threads locals even with 
>> thread groups, etc. As far as I understand Go has no concept of parent Go 
>> routine - at least not exposed - so I don’t see the issue.
> 
> The difference is that in Java creating a new thread is a relatively
> heavyweight operation.  It's not hard, but it's not routine.  It's
> reasonable that when creating a new thread you consider how to handle
> any thread local variables.  In particular everybody understands that
> the new thread will not have access to any of the thread local
> variables of the parent thread.
> 
> In Go new goroutines are started frequently and casually.  For
> example, it's routine for people to change a loop computing a list of
> values into a loop that starts a goroutine for each computation.  If
> we are using a thread-local context.Context to cancel a goroutine,
> then one would naturally expect all those goroutines to inherit that
> Context value, so that they too will be stopped.  If they don't
> inherit it, then we need some extra mechanism to set the thread-local
> Context, and we need to remember to do that.  If they do inherit it,
> then we need to think about the cases where they shouldn't inherit it.
> Either way, the operation is sometimes implicit and sometimes
> explicit.  That is confusing.
> 
> In Java it's not confusing to always make thread-local handling
> explicit.  In Go that would be frustrating and awkward.
> 
> 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] what is the use of context in golang RESTful apis?

[Ian Lance Taylor]

> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  wrote:
>
>
> I don’t see the complexity nor the real difference between Go routines and 
> Threads. In Java TLS is not passed to new threads you need to be explicit. 
> The ThreadLocal doesn’t allow  access to other threads locals even with 
> thread groups, etc. As far as I understand Go has no concept of parent Go 
> routine - at least not exposed - so I don’t see the issue.

The difference is that in Java creating a new thread is a relatively
heavyweight operation.  It's not hard, but it's not routine.  It's
reasonable that when creating a new thread you consider how to handle
any thread local variables.  In particular everybody understands that
the new thread will not have access to any of the thread local
variables of the parent thread.

In Go new goroutines are started frequently and casually.  For
example, it's routine for people to change a loop computing a list of
values into a loop that starts a goroutine for each computation.  If
we are using a thread-local context.Context to cancel a goroutine,
then one would naturally expect all those goroutines to inherit that
Context value, so that they too will be stopped.  If they don't
inherit it, then we need some extra mechanism to set the thread-local
Context, and we need to remember to do that.  If they do inherit it,
then we need to think about the cases where they shouldn't inherit it.
Either way, the operation is sometimes implicit and sometimes
explicit.  That is confusing.

In Java it's not confusing to always make thread-local handling
explicit.  In Go that would be frustrating and awkward.

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.

[go-nuts] Re: Using "er" and "able" for interfaces

[Roberto Zanotto]

Java is object-oriented, Go is subject-oriented :)

On Wednesday, January 16, 2019 at 3:42:38 PM UTC+1, Victor Giordano wrote:
>
>
> As far i can get to understand the english language (i'm not a native 
> speaker), the "er" seems to denotes or describe things in a more "active 
> way" (the thing that they actually do by itself), and the "able" describes 
> things in a more "passive way"  (the thing that you can "ask it/his/her" to 
> do). Do you find this appreciation correct?
>
>

-- 
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] Using "er" and "able" for interfaces

[Ian Denhardt]

Quoting Victor Giordano (2019-01-16 12:44:57)

>"able" describes things in a more "passive way"�  (the thing that you
>can "ask it/his/her" to do). Do you find this appreciation correct?

Pretty close, but a subtle point is that "-able" makes something the
indirect object, so for example it is not quite right to say that a
"writable" is something that you can ask to do writing -- it is the
thing being written to, whereas the thing doing the writing is a
"writer". In the case of io.Writer either one kindof makes sense, but
the meaning *is* slightly different.

When both are reasonable, -er is generally more idiomatic Go -- but
that's not always the case.

>The Go idiomatic style is to use the '-er' suffix. But this can
>sometimes lead to strange or obscure names even for native English
>speakers.

>For example, an interface with a "Stale() bool" method seems very
>strange when named as "Staler". All these sound weird: Lookuper,
>Errorer, Nexter

The problem with most of these is that the base words aren't verbs; the
-er suffix converts a verb, describing an action, into a noun describing
the thing or person that performs that action -- but "next" isn't an
action, so "nexter" sounds weird.

lookup is a little different -- "I lookup information" scans poorly, and
I'd probably write it as "I look up something" or better yet "I look
something up" -- so that probably has something to do with it, but I
don't know how to describe the rule precisely. Ironically, I often have
an easier time describing grammar rules precisely for German, because
being a native English speaker I didn't learn English grammar in as
structured a way.  :P

-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.

[go-nuts] Libvmi help to find hollowed processes in Win 10 operating system

[peddojusuresh]

I came to know from Volatility hollowfind that, they are using VAD and PEB 
structures to find process hollowing. In this process, I am trying to get 
details of VAD information from Win 10 image rekall profile with Libvmi. 
Then I can compare PEB and VAD structures to find discrepancies. Can anyone 
please help me in this regard. 

-- 
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] Using "er" and "able" for interfaces

[Victor Giordano]

Thanks you both gentleman for sharing your point of view on this!
I shall assume that the convention doesn't fit in 100% of the cases.

Greetings
V

El miércoles, 16 de enero de 2019, 12:38:22 (UTC-3), Ian Davis escribió:
>
> On Wed, 16 Jan 2019, at 2:42 PM, Victor Giordano wrote:
>
> As far i can get to understand the english language (i'm not a native 
> speaker), the "er" seems to denotes or describe things in a more "active 
> way" (the thing that they actually do by itself), and the "able" describes 
> things in a more "passive way"  (the thing that you can "ask it/his/her" to 
> do). Do you find this appreciation correct?
>
>
> This is correct.
>
> The Go idiomatic style is to use the '-er' suffix. But this can sometimes 
> lead to strange or obscure names even for native English speakers.
>
> For example, an interface with a "Stale() bool" method seems very strange 
> when named as "Staler". All these sound weird: Lookuper, Errorer, Nexter
>
> My preference is for naming to be clear and understandable as I can make 
> it. I use '-er' if it makes sense, then maybe '-able' or even something 
> that captures something from the domain the usual ones being Logger or 
> DataStore.
>
> All the best,
>
> 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] what is the use of context in golang RESTful apis?

[Robert Engels]

Sorry to the group, that message was only supposed to go to Ian... I guess I 
need retraining on using email. 

> On Jan 16, 2019, at 10:09 AM, Robert Engels  wrote:
> 
> Stupid iOS. I don’t even see a way to resend. Oh well. 
> 
>> On Jan 16, 2019, at 10:07 AM, Robert Engels  wrote:
>> 
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: Ian Lance Taylor 
>>> Date: January 16, 2019 at 9:29:59 AM CST
>>> To: Robert Engels 
>>> Subject: Re: [go-nuts] what is the use of context in golang RESTful apis?
>>> 
>>> This just came to me, not to the mailing list.  Was that a mistake?
>>> 
>>> Ian
>>> 
 On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  
 wrote:
 
 I don’t see the complexity nor the real difference between Go routines and 
 Threads. In Java TLS is not passed to new threads you need to be explicit. 
 The ThreadLocal doesn’t allow  access to other threads locals even with 
 thread groups, etc. As far as I understand Go has no concept of parent Go 
 routine - at least not exposed - so I don’t see the issue.
 
 Can you maybe give an example of where ThreadLocal type implementation is 
 confusing?
 
>> On Jan 16, 2019, at 9:00 AM, Ian Lance Taylor  wrote:
>> 
>> On Wed, Jan 16, 2019 at 5:39 AM Robert Engels  
>> wrote:
>> 
>> A big difference of opinion here.  TLS as implemented in Java via 
>> ThreadLocal is trivial to use, understand, and is pervasive. In C++ its 
>> a different story.
> 
> A general form of TLS is much more confusing in a language where it's
> trivial to start a goroutine.  To be at all useful we have to start
> talking about how and when goroutines inherit TLS values from their
> parent goroutine.  Then we need to control that.  It's a pile of
> complexity we don't need.  Better to be explicit.  In my opinion.
> 
> 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.
> -- 
> 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] what is the use of context in golang RESTful apis?

[Robert Engels]

Asan aside, I’ve never understood why the group messages don’t come from the 
group so a simple reply is all that is needed but then sometimes they do it 
seems...

> On Jan 16, 2019, at 10:07 AM, Robert Engels  wrote:
> 
> 
> 
> 
> Begin forwarded message:
> 
>> From: Ian Lance Taylor 
>> Date: January 16, 2019 at 9:29:59 AM CST
>> To: Robert Engels 
>> Subject: Re: [go-nuts] what is the use of context in golang RESTful apis?
>> 
>> This just came to me, not to the mailing list.  Was that a mistake?
>> 
>> Ian
>> 
>>> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  wrote:
>>> 
>>> I don’t see the complexity nor the real difference between Go routines and 
>>> Threads. In Java TLS is not passed to new threads you need to be explicit. 
>>> The ThreadLocal doesn’t allow  access to other threads locals even with 
>>> thread groups, etc. As far as I understand Go has no concept of parent Go 
>>> routine - at least not exposed - so I don’t see the issue.
>>> 
>>> Can you maybe give an example of where ThreadLocal type implementation is 
>>> confusing?
>>> 
> On Jan 16, 2019, at 9:00 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Jan 16, 2019 at 5:39 AM Robert Engels  
> wrote:
> 
> A big difference of opinion here.  TLS as implemented in Java via 
> ThreadLocal is trivial to use, understand, and is pervasive. In C++ its a 
> different story.
 
 A general form of TLS is much more confusing in a language where it's
 trivial to start a goroutine.  To be at all useful we have to start
 talking about how and when goroutines inherit TLS values from their
 parent goroutine.  Then we need to control that.  It's a pile of
 complexity we don't need.  Better to be explicit.  In my opinion.
 
 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.

-- 
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] what is the use of context in golang RESTful apis?

[Robert Engels]

Stupid iOS. I don’t even see a way to resend. Oh well. 

> On Jan 16, 2019, at 10:07 AM, Robert Engels  wrote:
> 
> 
> 
> 
> Begin forwarded message:
> 
>> From: Ian Lance Taylor 
>> Date: January 16, 2019 at 9:29:59 AM CST
>> To: Robert Engels 
>> Subject: Re: [go-nuts] what is the use of context in golang RESTful apis?
>> 
>> This just came to me, not to the mailing list.  Was that a mistake?
>> 
>> Ian
>> 
>>> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  wrote:
>>> 
>>> I don’t see the complexity nor the real difference between Go routines and 
>>> Threads. In Java TLS is not passed to new threads you need to be explicit. 
>>> The ThreadLocal doesn’t allow  access to other threads locals even with 
>>> thread groups, etc. As far as I understand Go has no concept of parent Go 
>>> routine - at least not exposed - so I don’t see the issue.
>>> 
>>> Can you maybe give an example of where ThreadLocal type implementation is 
>>> confusing?
>>> 
> On Jan 16, 2019, at 9:00 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Jan 16, 2019 at 5:39 AM Robert Engels  
> wrote:
> 
> A big difference of opinion here.  TLS as implemented in Java via 
> ThreadLocal is trivial to use, understand, and is pervasive. In C++ its a 
> different story.
 
 A general form of TLS is much more confusing in a language where it's
 trivial to start a goroutine.  To be at all useful we have to start
 talking about how and when goroutines inherit TLS values from their
 parent goroutine.  Then we need to control that.  It's a pile of
 complexity we don't need.  Better to be explicit.  In my opinion.
 
 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.

-- 
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.

Fwd: [go-nuts] what is the use of context in golang RESTful apis?

[Robert Engels]

Begin forwarded message:

> From: Ian Lance Taylor 
> Date: January 16, 2019 at 9:29:59 AM CST
> To: Robert Engels 
> Subject: Re: [go-nuts] what is the use of context in golang RESTful apis?
> 
> This just came to me, not to the mailing list.  Was that a mistake?
> 
> Ian
> 
>> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels  wrote:
>> 
>> I don’t see the complexity nor the real difference between Go routines and 
>> Threads. In Java TLS is not passed to new threads you need to be explicit. 
>> The ThreadLocal doesn’t allow  access to other threads locals even with 
>> thread groups, etc. As far as I understand Go has no concept of parent Go 
>> routine - at least not exposed - so I don’t see the issue.
>> 
>> Can you maybe give an example of where ThreadLocal type implementation is 
>> confusing?
>> 
 On Jan 16, 2019, at 9:00 AM, Ian Lance Taylor  wrote:
 
 On Wed, Jan 16, 2019 at 5:39 AM Robert Engels  
 wrote:
 
 A big difference of opinion here.  TLS as implemented in Java via 
 ThreadLocal is trivial to use, understand, and is pervasive. In C++ its a 
 different story.
>>> 
>>> A general form of TLS is much more confusing in a language where it's
>>> trivial to start a goroutine.  To be at all useful we have to start
>>> talking about how and when goroutines inherit TLS values from their
>>> parent goroutine.  Then we need to control that.  It's a pile of
>>> complexity we don't need.  Better to be explicit.  In my opinion.
>>> 
>>> 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] Using "er" and "able" for interfaces

[Ian Davis]

On Wed, 16 Jan 2019, at 2:42 PM, Victor Giordano wrote:
> As far i can get to understand the english language (i'm not a native 
> speaker), the "er" seems to denotes or describe things in a more "active way" 
> (the thing that they actually do by itself), and the "able" describes things 
> in a more "passive way" (the thing that you can "ask it/his/her" to do). Do 
> you find this appreciation correct?

This is correct.

The Go idiomatic style is to use the '-er' suffix. But this can sometimes lead 
to strange or obscure names even for native English speakers.

For example, an interface with a "Stale() bool" method seems very strange when 
named as "Staler". All these sound weird: Lookuper, Errorer, Nexter

My preference is for naming to be clear and understandable as I can make it. I 
use '-er' if it makes sense, then maybe '-able' or even something that captures 
something from the domain the usual ones being Logger or DataStore.

All the best,

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] what is the use of context in golang RESTful apis?

[Robert Engels]

One other note, I think passing the context around is very limited compared to 
TLS based usage. In well written frameworks the context is provided by and 
controlled by the container allowing for very advanced AOP style injections 
where appropriate (logging, security, transactions, etc)

Having direct control over the context seems like asking for brittle code and 
more obscure bugs (e.g. some method call replaces the context as they call the 
next). 

> On Jan 16, 2019, at 9:00 AM, Ian Lance Taylor  wrote:
> 
>> On Wed, Jan 16, 2019 at 5:39 AM Robert Engels  wrote:
>> 
>> A big difference of opinion here.  TLS as implemented in Java via 
>> ThreadLocal is trivial to use, understand, and is pervasive. In C++ its a 
>> different story.
> 
> A general form of TLS is much more confusing in a language where it's
> trivial to start a goroutine.  To be at all useful we have to start
> talking about how and when goroutines inherit TLS values from their
> parent goroutine.  Then we need to control that.  It's a pile of
> complexity we don't need.  Better to be explicit.  In my opinion.
> 
> 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] Using "er" and "able" for interfaces

[Robert Engels]

Your thinking is correct, but Java has a Reader class as well. I prefer the 
able format, but it depends. You have interfaces like Predicate in Java and not 
Testable. You also have Runnable and not Runner.  In summary - it depends :)

> On Jan 16, 2019, at 8:42 AM, Victor Giordano  wrote:
> 
> Hello all! 
> I don't know very well what is the topic about using "er" or "able" or any 
> other suffix for the single method interfaces (a.k.a. "funcitonal 
> interfaces"), but i would like to address some thoughts, hope you can bear 
> with me, here we go:
> 
> If a take a look to the Readable interface in Java and the io.Reader 
> interface in Golang, i would say the these "two" persons (assuming that they 
> actually were different persons) were thinking in the same thing (i mean, an 
> object to which you can send it a message [or invoke method] to read bytes or 
> chars, let's bear with me here and let's aggree that both interfaces as 
> abstractions has the same intend) but use different naming, right?
> 
> As far i can get to understand the english language (i'm not a native 
> speaker), the "er" seems to denotes or describe things in a more "active way" 
> (the thing that they actually do by itself), and the "able" describes things 
> in a more "passive way"  (the thing that you can "ask it/his/her" to do). Do 
> you find this appreciation correct?
> 
> I really hope to reach someone who has already thought about this and share 
> the doubts. 
> 
> 
> -- 
> 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] what is the use of context in golang RESTful apis?

[Ian Lance Taylor]

On Wed, Jan 16, 2019 at 5:39 AM Robert Engels  wrote:
>
> A big difference of opinion here.  TLS as implemented in Java via ThreadLocal 
> is trivial to use, understand, and is pervasive. In C++ its a different story.

A general form of TLS is much more confusing in a language where it's
trivial to start a goroutine.  To be at all useful we have to start
talking about how and when goroutines inherit TLS values from their
parent goroutine.  Then we need to control that.  It's a pile of
complexity we don't need.  Better to be explicit.  In my opinion.

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.

[go-nuts] Using "er" and "able" for interfaces

[Victor Giordano]

Hello all!
I don't know very well what is the topic about using "er" or "able" or any
other suffix for the single method interfaces (a.k.a. "funcitonal
interfaces"), but i would like to address some thoughts, hope you can bear
with me, here we go:

If a take a look to the Readable interface in Java and the io.Reader
interface in Golang, i would say the these "two" persons (assuming that
they actually were different persons) were thinking in the same thing (i
mean, an object to which you can send it a message [or invoke method] to
read bytes or chars, let's bear with me here and let's aggree that both
interfaces as abstractions has the same intend) but use different naming,
right?

As far i can get to understand the english language (i'm not a native
speaker), the "er" seems to denotes or describe things in a more "active
way" (the thing that they actually do by itself), and the "able" describes
things in a more "passive way"  (the thing that you can "ask it/his/her" to
do). Do you find this appreciation correct?

I really hope to reach someone who has already thought about this and share
the doubts.

-- 
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] what is the use of context in golang RESTful apis?

[Robert Engels]

A big difference of opinion here.  TLS as implemented in Java via ThreadLocal 
is trivial to use, understand, and is pervasive. In C++ its a different story. 

> On Jan 16, 2019, at 3:17 AM, alex.besogo...@gmail.com wrote:
> 
> TLS most certainly does not make stuff easier. It just obscures it.
> 
> The decision to remove TLS from Go was right. Explicit is better than 
> implicit, even if it does make logging quite a bit clumsier.
> 
> That being said, Context API could use a re-design.
> 
>> On Monday, January 14, 2019 at 7:37:25 AM UTC-8, robert engels wrote:
>> I mostly concur - Go really needs TLS - simplifies this sort of thing. You 
>> can look at many “complex” Java based server systems and the method calls 
>> are far simpler in the common case (especially when using a framework that 
>> leverages TLS).
>> 
>> I think a key issue is that most ‘requests’ are not long-enough lived for 
>> the cancellation context to be warranted - otherwise the site would be too 
>> slow anyway. You see this need in “background jobs” - and still, these jobs 
>> are usually per server/application, not per user or per request.
>> 
>> Systems that perform time consuming data analysis jobs on behalf of a user 
>> are a different case, and they clearly need a way to stop their processing.
>> 
>> And yes the ‘not type safe api’ for values is a problem. If Go really wants 
>> to promote the context as ubiquitous it should have built-in language 
>> support to address these issues (type safety, no need for TLS, required at 
>> Go routine creation site, etc.).
>> 
>> 
>> 
>>> On Jan 13, 2019, at 6:35 PM, Space A.  wrote:
>>> 
>>> I just leave it here
>>> 
>>> Context should go away for Go 2
>>> 
>>> 
>>> 
>>> 
>>> воскресенье, 13 января 2019 г., 22:21:50 UTC+3 пользователь Tamás Gulácsi 
>>> написал:
 
 -BEGIN PGP SIGNED MESSAGE- 
 Hash: SHA256 
 
 There should be a "global" or parent Context, which is canceled when the 
 server is going to shut down (e.g. with signal.Notify), and each handler 
 should create a child context with a proper timeout. 
 
 And it should watch the request's Context, too, as that's what will be 
 canceled when the client disconnects. github.com/LK4D4/joincontext may 
 help with tis. 
 
 But if you use the request's Context only with a propert timeout, that's 
 already better than doing nothing. 
 
 Tamás 
 
 
 ‐‐‐ Original Message ‐‐‐ 
 On 2019. January 13., Sunday 19:49, Mahendra Bhoir  
 wrote: 
 
 > That makes sense.. So where should declare my context variable? Inside 
 > handler function or in main function As handler itself is a goroutine.. 
 > 
 > On Sun, Jan 13, 2019 at 11:24 PM Justin Israel  
 > wrote: 
 > 
 > > On Mon, Jan 14, 2019, 2:23 AM Mahendra Bhoir  
 > > wrote: 
 > > 
 > > > APIs I have written are for mobile applications and request 
 > > > cancellation doesn’t happen much on mobile applications. 
 > > 
 > > What if the mobile client closes the app in the middle of an expensive 
 > > request?  
 > > 
 > > > I think I am little confused with uses of context. 
 > > > 
 > > > I found this page on Internet about context. I this will clear my 
 > > > confusions.. 
 > > > 
 > > > https://www.sohamkamani.com/blog/golang/2018-06-17-golang-using-context-cancellation/#listening-for-the-cancellation-event
 > > >  
 > > > 
 > > > On Sun, 13 Jan 2019 at 6:24 PM, Tamás Gulácsi  
 > > > wrote: 
 > > > 
 > > > > Timing out and cancellation are the main uses of Context. 
 > > > > 
 > > > > How do you cancel processing when the client clises the 
 > > > > connection? 
 > > > > 
 > > > > -- 
 > > > > 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. 
 > > > 
 > > > -- 
 > > > Mahendra Bhoir.  
 > > > +919545688916 
 > > > 
 > > > -- 
 > > > 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. 
 > 
 > -- 
 > Mahendra Bhoir.  
 > +919545688916 
 -BEGIN PGP SIGNATURE- 
 Version: ProtonMail 
 Comment: https://protonmail.com 
 
 wsBcBAEBCAAGBQJcO4+hAAoJELj70Bsqr19tI9QIAIwrPJKrRlALTtOxnDY8 
 qoLippDAevQxpAzpQYW6w5VN7eDrxdXUrIH1gHGXYJPYOv/J7/i4gbK1txW0 
 rQaaKpR8JmCY6CDdaQaTVg50XeC3yApFJPEeRZazLztnmKi6HB6PQhgGondA 
 

Re: [go-nuts] performance optimization

[Jesper Louis Andersen]

On Wed, Jan 16, 2019 at 11:55 AM Wojciech S. Czarnecki 
wrote:


> You can't expect a million interrupts per second and host OS running
> simultaneously.
> (1us gives some 4k instructions inbetween on recent 3GHz cpu core)
>
>
And to add: if you do anything with memory, it is usually considerably less
than that. DRAM access in particular can be shaving many of those 4k
instructions off very easily.

If possible, it is usually better to fill out work for the future when you
are on-CPU, because you don't necessarily know when you come back to the
CPU core. This hides the latency.

-- 
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] performance optimization

[Wojciech S. Czarnecki]

On Mon, 14 Jan 2019 21:34:34 +0100
Tamás Király  wrote:

> I'm simulating the internal clock of an embedded microcontroller...

You can't expect a million interrupts per second and host OS running 
simultaneously.
(1us gives some 4k instructions inbetween on recent 3GHz cpu core) 

Usual way for emulating hw state machines maintaining RT accuracy:

loop:

1. make a batch "n" of emulated hw instructions that span observable
i/o ops or shared state commits; then

2. count expected 'hw cycles' above batch would need on real hw,
duration "d" of real time it would take then "t" point of time batch 
results are due; then

3. set "hw progress" timer P to "t" point

4. "execute" batch "n"
(at full host speed of course, hw logic/instructions are
transpiled to host instruction set)

5. sleep (give cpu to host OS) until P fires

6. commit state (results of batch) "n"
n += 1; 
goto loop

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] what is the use of context in golang RESTful apis?

[alex . besogonov]

TLS most certainly does not make stuff easier. It just obscures it.

The decision to remove TLS from Go was right. Explicit is better than 
implicit, even if it does make logging quite a bit clumsier.

That being said, Context API could use a re-design.

On Monday, January 14, 2019 at 7:37:25 AM UTC-8, robert engels wrote:
>
> I mostly concur - Go really needs TLS - simplifies this sort of thing. You 
> can look at many “complex” Java based server systems and the method calls 
> are far simpler in the common case (especially when using a framework that 
> leverages TLS).
>
> I think a key issue is that most ‘requests’ are not long-enough lived for 
> the cancellation context to be warranted - otherwise the site would be too 
> slow anyway. You see this need in “background jobs” - and still, these jobs 
> are usually per server/application, not per user or per request.
>
> Systems that perform time consuming data analysis jobs on behalf of a user 
> are a different case, and they clearly need a way to stop their processing.
>
> And yes the ‘not type safe api’ for values is a problem. If Go really 
> wants to promote the context as ubiquitous it should have built-in language 
> support to address these issues (type safety, no need for TLS, required at 
> Go routine creation site, etc.).
>
>
>
> On Jan 13, 2019, at 6:35 PM, Space A. > 
> wrote:
>
> I just leave it here
>
> Context should go away for Go 2 
> 
>
>
>
> воскресенье, 13 января 2019 г., 22:21:50 UTC+3 пользователь Tamás Gulácsi 
> написал:
>>
>> -BEGIN PGP SIGNED MESSAGE- 
>> Hash: SHA256 
>>
>> There should be a "global" or parent Context, which is canceled when the 
>> server is going to shut down (e.g. with signal.Notify), and each handler 
>> should create a child context with a proper timeout. 
>>
>> And it should watch the request's Context, too, as that's what will be 
>> canceled when the client disconnects. github.com/LK4D4/joincontext may 
>> help with tis. 
>>
>> But if you use the request's Context only with a propert timeout, that's 
>> already better than doing nothing. 
>>
>> Tamás 
>>
>>
>> ‐‐‐ Original Message ‐‐‐ 
>> On 2019. January 13., Sunday 19:49, Mahendra Bhoir  
>> wrote: 
>>
>> > That makes sense.. So where should declare my context variable? Inside 
>> handler function or in main function As handler itself is a goroutine.. 
>> > 
>> > On Sun, Jan 13, 2019 at 11:24 PM Justin Israel  
>> wrote: 
>> > 
>> > > On Mon, Jan 14, 2019, 2:23 AM Mahendra Bhoir  
>> wrote: 
>> > > 
>> > > > APIs I have written are for mobile applications and request 
>> cancellation doesn’t happen much on mobile applications. 
>> > > 
>> > > What if the mobile client closes the app in the middle of an 
>> expensive request?  
>> > > 
>> > > > I think I am little confused with uses of context. 
>> > > > 
>> > > > I found this page on Internet about context. I this will clear my 
>> confusions.. 
>> > > > 
>> > > > 
>> https://www.sohamkamani.com/blog/golang/2018-06-17-golang-using-context-cancellation/#listening-for-the-cancellation-event
>>  
>> > > > 
>> > > > On Sun, 13 Jan 2019 at 6:24 PM, Tamás Gulácsi  
>> wrote: 
>> > > > 
>> > > > > Timing out and cancellation are the main uses of Context. 
>> > > > > 
>> > > > > How do you cancel processing when the client clises the 
>> connection? 
>> > > > > 
>> > > > > -- 
>> > > > > 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. 
>> > > > 
>> > > > -- 
>> > > > Mahendra Bhoir.  
>> > > > +919545688916 
>> > > > 
>> > > > -- 
>> > > > 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. 
>> > 
>> > -- 
>> > Mahendra Bhoir.  
>> > +919545688916 
>> -BEGIN PGP SIGNATURE- 
>> Version: ProtonMail 
>> Comment: https://protonmail.com 
>>
>> wsBcBAEBCAAGBQJcO4+hAAoJELj70Bsqr19tI9QIAIwrPJKrRlALTtOxnDY8 
>> qoLippDAevQxpAzpQYW6w5VN7eDrxdXUrIH1gHGXYJPYOv/J7/i4gbK1txW0 
>> rQaaKpR8JmCY6CDdaQaTVg50XeC3yApFJPEeRZazLztnmKi6HB6PQhgGondA 
>> edpsPOQejfLe9KMhN+7RJzVjwWYHYwZXyMIITQT8/jADip3AAZWKojcXFpJq 
>> 7MfWfIjru0+tT5+hSfLr8JZpimMwhmOoW8xVeTKmZkXonucky5E3WmJUEPEv 
>> 3lcQQVZI3827PLeMKsKd6UpI2x2CcCqLPInIeEzVsDjhWURI2gznWv2Sqj6v 
>> T3wS3oVXoJo28sgb9ViyEC0= 
>> =1E4l 
>> -END PGP SIGNATURE- 
>>
>>
> -- 
> 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