[go-nuts] Using xml.Encoder.Encode over xml.Encoder.EncodeElement

[Uwe Dauernheim]

Is there a downside in using `xml.Encode` instead of `xml.EncodeElement` 
when implementing the `xml.Marshaler` interface?

I see in the documentation:

Using start as the element tag is not required, but doing so will 
enable Unmarshal to match the XML elements to the correct struct field.

But am not sure if not leveraging "will enable..." does have a concrete 
downside?

I marshal a type `Amount` to `42` via 
`xml.Encoder.Encode`: https://play.golang.org/p/64FC-j0FyA . 

If I however use `xml.Encoder.EncodeElement` I get: `42` (uppercased).




-- 
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] Why is ioutil.Discard implemented using an int and not an empty struct?

[Rodolfo Carvalho]

Hi,

I noticed that when io.Discard was introduced in
https://codereview.appspot.com/4426066/, it replaced code like:

type devNull struct{}


With:


type devNull int


Both had the very same implementation of the Write method:

func (devNull) Write(p []byte) (int, os.Error) {
 return len(p), nil
}



What's the advantage of using an int in this case, if any?


Thank you,

Rodolfo Carvalho

-- 
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] Excessive garbage collection

[jiri . simsa]

Hello,

The backend of my web server (written in Go) have recently started 
consuming large amounts of CPU. AFAICT, the CPU seems to be consumed by the 
garbage collector and I would appreciate any information that would help me 
track down the root cause.

When I run the web server with gctrace=1, I see the following trace:

gc 1 @6.033s 0%: 0.096+0.92+0.053 ms clock, 0.19+0.056/0.51/0.89+0.10 ms cpu, 
4->4->0 MB, 5 MB goal, 2 P
gc 2 @19.072s 0%: 0.010+0.89+0.043 ms clock, 0.021+0.015/0.55/0.67+0.086 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 3 @32.111s 0%: 0.031+0.95+0.051 ms clock, 0.062+0/0.80/0.38+0.10 ms cpu, 
4->4->0 MB, 5 MB goal, 2 P
gc 4 @45.151s 0%: 0.098+0.80+0.28 ms clock, 0.19+0/0.44/0.77+0.57 ms cpu, 
4->4->0 MB, 5 MB goal, 2 P
gc 5 @58.193s 0%: 0.010+1.1+0.045 ms clock, 0.020+0.050/0.33/1.0+0.090 ms cpu, 
4->4->0 MB, 5 MB goal, 2 P
gc 6 @71.235s 0%: 0.026+0.73+0.056 ms clock, 0.053+0/0.72/0.42+0.11 ms cpu, 
4->4->0 MB, 5 MB goal, 2 P


In particular, garbage collection happens every 10-15 seconds. Now when I 
use a browser to navigate to a page that triggers the odd behavior, I see 
the following trace:

gc 7640 @187.367s 1%: 0.007+0.66+0.23 ms clock, 0.014+0.008/0.35/0.62+0.47 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7641 @187.376s 1%: 0.007+0.56+0.23 ms clock, 0.014+0.008/0.46/0.53+0.46 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7642 @187.386s 1%: 0.008+0.63+0.24 ms clock, 0.016+0.008/0.59/0.35+0.49 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7643 @187.395s 1%: 0.008+0.61+0.28 ms clock, 0.016+0.009/0.37/0.58+0.56 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7644 @187.405s 1%: 0.009+0.55+0.030 ms clock, 0.018+0.009/0.46/0.52+0.060 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7645 @187.414s 2%: 0.008+0.56+0.25 ms clock, 0.017+0.008/0.47/0.52+0.51 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7646 @187.424s 2%: 0.008+0.69+0.017 ms clock, 0.016+0.008/0.66/0.36+0.034 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7647 @187.433s 2%: 0.008+0.61+0.018 ms clock, 0.017+0.008/0.35/0.60+0.037 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7648 @187.442s 2%: 0.008+0.67+0.26 ms clock, 0.017+0.008/0.65/0.38+0.52 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P
gc 7649 @187.452s 2%: 0.008+0.65+0.24 ms clock, 0.016+0.008/0.36/0.61+0.48 ms 
cpu, 4->4->0 MB, 5 MB goal, 2 P


In particular, garbage collection happens every 10 ms. The page that 
triggers this behavior periodically fetches and displays some in-memory 
state from the backend and the excessive GC behavior continues even after 
the page that triggers the behavior is closed.

I should add that the web server backend has multiple goroutines running in 
the background performing periodic activity, but none of the background 
activity is triggered or influenced by the incoming HTTP request for the 
culprit page.

Any suggestions as to what steps I can take to investigate this problem 
further would be greatly appreciated. 

I am happy to provide more details about the implementation of the web 
server but I am not sure what else could be relevant.

Cheers,

-- 
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] Excessive garbage collection

[Ian Lance Taylor]

On Mon, Oct 17, 2016 at 6:20 PM,   wrote:
>
> The backend of my web server (written in Go) have recently started consuming
> large amounts of CPU. AFAICT, the CPU seems to be consumed by the garbage
> collector and I would appreciate any information that would help me track
> down the root cause.

What version of Go?  What platform?

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] Excessive garbage collection

[Jiří Šimša]

go version go1.7.1 darwin/amd64

--
Jiří Šimša

On Mon, Oct 17, 2016 at 8:02 PM, Ian Lance Taylor  wrote:

> On Mon, Oct 17, 2016 at 6:20 PM,   wrote:
> >
> > The backend of my web server (written in Go) have recently started
> consuming
> > large amounts of CPU. AFAICT, the CPU seems to be consumed by the garbage
> > collector and I would appreciate any information that would help me track
> > down the root cause.
>
> What version of Go?  What platform?
>
> 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] Re: Serialization internal data to disk

[Tong Sun]

On Mon, Oct 17, 2016 at 1:20 AM, Tamás Gulácsi wrote:

>
>
>> The reason that I didn't do it, is because I don't know how to do it. In
>> essence, that "f.Close()" that you worried about is wrapped in "defer
>> f.Close()" in SaveState, which in turn wrapped in "defer SaveState" in a
>> function. I.e., all is happening during the program tear-down phase. If we
>> are not planting a "log.Fatal(err)" bomb in SaveState itself, how do you
>> think we should check it properly?
>>
>>
> There are several possibilities. Two easy:
> 1. use a named return parameter:
> func SaveState(...) (err error) {
> ...
> // close the file and return the error
> defer func() {
>   if closeErr := f.Close(); closeErr != nil && err == nil {
> err = closeErr
> }()
> ...
> }
>

That method will interfere with/overwrite the existing return logic right?

Basically, my "func SaveState(...) error" has "return gob.NewEncoder(f).
Encode(state)" as the last statement:

func SaveState(persistName string, state interface{}) error {
// create persistence file
f, err := os.Create(persistName)
if err != nil {
return err
}
defer f.Close()
// write persistemce file
err = gob.NewEncoder(f).Encode(state)
return err
}

if using the method 1, then if the gob.NewEncoder(f).Encode(state) fails,
but defer f.Close() works, the true error will be lost, right?


> 2. Treat the defer f.Close() just as a resource releaser for error path,
> and do an "return f.Close()" anyway:
> func SaveState(...) error {
> ...
> defer f.Close() // just release resources on error paths
> ...
> return f.Close() // never lose the error of Close!
> }
>
> yes, this does call f.Close() twice, and the second (the defer) will error
> out, but that does no harm.
>

OK, will try to do that, and report back...

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam Breck]

On Oct 16, 2016 6:03 PM, "Liam Breck"  wrote:
>
>
>
> On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor  wrote:
>>
>> On Sun, Oct 16, 2016 at 5:25 PM, Liam  wrote:
>> >
>> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor
wrote:
>> >>
>> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam  wrote:
>> >> >
>> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor
wrote:
>> >> >
>> >> >> To argue that this should go into the standard library, look at
some
>> >> >> corpus of Go code and find out how often it occurs.  If it occurs
>> >> >> fairly often, you've got a good case.
>> >> >
>> >> >
>> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it
>> >> > passes
>> >> > that test.
>> >>
>> >> This is something that can actually be measured.
>> >
>> >
>> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
>> > Neither of these will be accurate.
>> >
>> > Part of my point is that Insert operations are semantically obscured.
>>
>> Understood.  But my guess is that insertion operations are fairly
>> rare--much less common than Replace or Trim.  People obviously append
>> to slices all the time, but I suspect that they tend to write their
>> slice operations to not require inserting a single element in the
>> middle of the slice, because insertion is by definition O(N) rather
>> than O(1).  I could certainly be wrong, but that guess leads me to
>> suspect that adding a function for something that can easily be
>> written in a single expression is overkill.  Since I am only guessing,
>> and since it seems to me that you are also guessing, I think we should
>> measure rather than guess.
>
>
> You characterize optimization as a widespread habit. Most code isn't
optimized, as it doesn't need to be. Most coders follow the first advice
found, which in my case was Insert() on [1]. If you wish the most optimal
solution to be widespread, stdlib would be a good vehicle :-)
>
> I would attempt to provide data confirming my guess, but I can't see how
to do that without spending a lot of time hunting for semantically
invisible operations. Since there are two authoritative suggestions for
this op, it's a reasonable guess that it's widely done.
>
> BTW, we are having this discussion because fmt does not support thousands
grouping, which also seems like a common need.
>
> [1] https://blog.golang.org/slices

As an alternative to bytes.Insert/Delete how about

bytes.Replace(s []byte, pos int, len uint, new []byte)

A zero len is insert, and empty new is delete.

-- 
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] simplifying freeing CString

[Pietro Gagliardi]

> On Oct 17, 2016, at 5:03 PM, andrew.sm...@miracl.com wrote:
> 
> Hi,
> 
> When using cgo its my understanding that strings created with C.CString must 
> be freed with C.free, but yet numeric types do not need to be explicitly 
> freed.

Yes. This is because strings in C are not first class objects like they are in 
Go. In C, a string is an array of bytes that ends with a byte whose value is 0, 
represented as '\0' in C and '\000' in Go.

When you create a string using the "..." syntax, the string is made part of the 
executable data. You cannot legally modify these strings, and they do not need 
to be freed. All other strings need to be stored in a buffer large enough for 
all those bytes (plus the extra null byte). This is analogous to manipulating a 
slice in Go. If the string is created at compile time (such as being stored in 
a char[512] or so), you don't have to worry about managing the memory. But a 
string created at runtime must be explicitly allocated, and since C does not 
have a garbage collector, must be explicitly freed as well.

> 
> Firstly, is CString a special case here, or are there other types that need 
> to be explicitly freed as well?

C.CString() is the most obvious case. C.CBytes() (new in 1.7) also counts, as 
does anything else allocated with the standard C malloc(), calloc(), and 
realloc() functions, either directly or indirectly.

> 
> Secondly, Im writing a lot of wrappers to cgo functions that will requiring 
> converting go 'string' arguments in the outer function, into C.String 
> arguments in the cgo inner function. Im looking for a simple way to ensure 
> that I dont create any memory leaks. In view of this I have an idea to wrap 
> the CString in a go struct and set the finalizer to free the CString :
> 
> // -- wrapped.go 
> --
> 
> package golasso
> 
> import (
> // #include 
> "C"
> "fmt"
> "runtime"
> "unsafe"
> )
> 
> type WrappedString struct {
> s *C.char
> }
> 
> func FreeWrappedString(s *WrappedString) {
> fmt.Print("Freeing WrappedString")
> C.free(unsafe.Pointer(s.s))
> }
> 
> func NewWrappedString(s string) WrappedString {
> wrappedString := WrappedString{s: C.CString(s)}
> runtime.SetFinalizer(, FreeWrappedString)
> return wrappedString
> }
> 
> 
> // --
> 
> func simulatedCCall(s *C.char) {
> 
> fmt.Print("simulated C call")
> 
> }
> 
> // -- wrapped_test.go 
> --
> package golasso
> 
> import (
> "runtime"
> "testing"
> )
> 
> func TestWrapped(t *testing.T) {
> simulatedCCall(NewWrappedString("fred").s)
> t.Logf("simulated C call")
> runtime.GC()
> }
> 
> 
> 
> 
> 
> 

I'm not sure what your question is. Idiomatic cgo code just uses defer though:

cstr := C.CString(str)
defer C.free(unsafe.Pointer(cstr))

> NB: I do realise that, in a production scenario, it might be a long time 
> before the GC runs and therefore a long time before the GC calls the 
> finalizer to free the CString. Im not so worried about this, as my primary 
> concern is ensuring that *every* CString is definitely going to be freed at 
> some point, and therefore I have no *true* memory leaks.
> 
> What are the pros/cons of this? Is it even correct? Is there an easier way to 
> achieve this?
> 

Finalizers are not guaranteed to run, even during a garbage collect. You may 
accidentally be letting your C string escape to the heap without knowing it. 
I'm not sure why we even have finalizers, or why they're public API.

Exposing C strings outside your package isn't really a good idea anyway. 
Convert when necessary to keep things safer.

> Andy
> 
> 
> -- 
> 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] output files from build of swig file

[andrew . smith]

Thanks for confirming my suspicions. 

I have a follow-up question, how can I instrument my go code so that I can 
set the include path that is used to resolve '%include' statements in my 
swig code. Currently I have relative paths in my swig file, and I would 
like to put '/usr/include' on the search path for the swig compilation. Is 
this possible?

On Friday, October 14, 2016 at 2:33:23 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Oct 14, 2016 at 3:42 AM,   
> wrote: 
> > 
> > Im trying to build a swig wrapper to a c library using go build. I know 
> the 
> > swig interface file is good as it builds correctly with the swig command 
> and 
> > generated the expected go wrapper file and the wrapper c file. I know it 
> has 
> > built because if I change the include paths in my  CGO_CFLAGS 
> environment 
> > variable the build fails to find the c library headers and fails. So it 
> > looks like it is building ok, but I dont see the go wrapper file 
> generated 
> > anywhere. Is this created as a temporary file and then discarded after 
> the 
> > build completes? Is there any way of forcing go build to output the swig 
> > wrappers in a specified directory? 
>
> There is no way to tell `go build` to put the SWIG output in a 
> specific place.  But you can use the -work option to preserve the 
> temporary directory where the SWIG outputs are generated, and the -x 
> option to see the exact commands that `go build` is executing. 
>
> 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] Re: Serialization internal data to disk

[Kiki Sugiaman]

On 17/10/16 23:09, Kiki Sugiaman wrote:


If N out of 4 error is not nil, N > 0, expect some performance hit from
reflection. If N == 0 (which should be most of the time), the code will
not touch reflection.



Sorry, I was referring to an earlier version that's still stuck in my 
head. There's no reflect anymore now, just type switch.





I consulted this mailing list a while back when writing this, so maybe
this is also a good opportunity to get some critique.




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
.
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: Proposal: add "future" internal type (similar to channel)

[adonovan via golang-nuts]

On Monday, 17 October 2016 10:10:47 UTC-4, Sokolov Yura wrote:
>
> Mutex needs not to be type-safe.
> And Mutex is not part of concept of "language tailored towards 
> concurrency". 
>

Go does not take a strong Erlang-like stance against concurrency with 
shared variables, so mutexes really are critical to Go's concurrency.

But "future" is well known, widely adopted (though, in different ways)
> concurrency primitive.
> It definitely has right to be part of "language for concurrency".
>
I've already implemented Futures as library code several times, but
> they are redundant.
> To build Future as a library code, you need:
> - redundant interface{}
> - redundant Mutex
> - you still need 'chan'
> - you need to wrap it in a struct
> - and then provide "convenient" redundant api.
>

This is really a special case of the argument for generics in Go.

Futures are to channels and stacks are to slices.  With generics, you could 
provide first-class Future and Stack, but without generics it's 
simply not worth the effort for most users to bother with the abstraction 
since it can be written in little more than a dozen lines of code: 
 https://play.golang.org/p/Obqag2hgZe  It's just easier to implement the 
underlying operations directly.

 

> But 99% of functionality is already in 'chan' implementation.
> And ":= <-" with "<-" is a perfect api for future.
> There is a need only in a (relatively) small change to runtime and (a
> bit larger) to compiler.
>

Adding a new data type is not a small change to the language.  It requires 
changes to the spec, the compiler, the reflect package, every program that 
uses the reflect package, every tool that manipulates Go source code, and 
many other things too.  The only types that currently enjoy special status 
in the type system are slice, map, channel and a small number of others, 
all of which are very widely used.


-- 
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] Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Konstantin

No, no sync.Cond.
Please, read links before writing answers.
Please.

понедельник, 17 октября 2016 г., 17:12:42 UTC+3 пользователь Konstantin 
Khomoutov написал:
>
> On Sun, 16 Oct 2016 05:40:32 -0700 (PDT) 
> Sokolov Yura  wrote: 
>
> > "future" is commonly used synchronization abstraction. 
> > 
> > It could be implemented in a library, using mutex, channel and 
> > interface. Example: 
> > 
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>  
> > 
> > But obviously, semantically future is just a channel with buffer of 
> > capacity 1, but receivers do not pop 
> > value from a buffer, but instead every receiver receive same value. 
> > And "filling" future awakes all 
> > receivers simultaneously, similar to "closing of channel". 
> > 
> > So I propose to introduce "future" as a same internal type as a 
> > "channel". It will share representation and lot of code with buffered 
> > channel (of capacity 1). 
> > 
> > https://github.com/golang/go/issues/17466 
>
> If I'm not mistaken, you propose to implement some abstraction atop of 
> the existing sync.Cond type. 
>
> I'm not sure this is needed: a library implementing a "future" type 
> will be like 50 lines of code -- basically combining a variable of type 
> sync.Cond with a variable of type interface{} plus small amount of glue 
> code. 
>

-- 
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] Why is ioutil.Discard implemented using an int and not an empty struct?

['Axel Wagner' via golang-nuts]

There is no semantic difference.

Disclaimer: On everything that follows, I'm not an expert (and it seems I'm
wrong. Not sure exactly how, though).

Though there *might* be a (*very*) slight advantage to using a struct{}.
All struct{}'s have the same address in gc, so if you put a struct{} into
an interface, that interface can be copied and compared directly.
If you put an int into an interface, it will need to be allocated
*somewhere* and you then put a pointer to it into the interface. And as, in
theory, the int could change, but a copy of the value shouldn't, it might
mean that when you assign ioutil.Discard to something else (or pass it to
some function as an io.Writer), that *may* incur an allocation.

However, the compiler might be clever enough to optimize that out with
inlining and escape analysis. And indeed, I'm failing to trigger the
behavior with any simple testcase. So I might be wrong here. Would be
interested in an experts explanation as to if that reasoning is
systematically broken :)

In any case, I don't think it'll make a practical difference.

On Mon, Oct 17, 2016 at 11:23 AM, Rodolfo Carvalho 
wrote:

> Hi,
>
> I noticed that when io.Discard was introduced in
> https://codereview.appspot.com/4426066/, it replaced code like:
>
> type devNull struct{}
>
>
> With:
>
>
> type devNull int
>
>
> Both had the very same implementation of the Write method:
>
> func (devNull) Write(p []byte) (int, os.Error) {
>  return len(p), nil
> }
>
>
>
> What's the advantage of using an int in this case, if any?
>
>
> Thank you,
>
> Rodolfo Carvalho
>
> --
> 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: Proposal: add "future" internal type (similar to channel)

[Юрий Соколов]

Mutex needs not to be type-safe.
And Mutex is not part of concept of "language tailored towards concurrency".

But "future" is well known, widely adopted (though, in different ways)
concurrency primitive.
It definitely has right to be part of "language for concurrency".
(ohhh, three lines of text with "concurrency" in... sorry for that)

I've already implemented Futures as library code several times, but
they are redundant.
To build Future as a library code, you need:
- redundant interface{}
- redundant Mutex
- you still need 'chan'
- you need to wrap it in a struct
- and then provide "convenient" redundant api.

But 99% of functionality is already in 'chan' implementation.
And ":= <-" with "<-" is a perfect api for future.
There is a need only in a (relatively) small change to runtime and (a
bit larger) to compiler.

With regards,
Sokolov Yura aka funny_falcon


2016-10-17 16:42 GMT+03:00 adonovan via golang-nuts
:
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>> It could be implemented in a library, using mutex, channel and interface.
>> Example:
>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
>
> If it can be implemented as a library, why build it in to the language?  You
> don't need futures very often---far less than, say, Mutex, and mutexes
> aren't built into the language either.
>
> --
> 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/yitP4iM4Y3k/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Mutex needs not to be type-safe.
And Mutex is not part of concept of "language tailored towards concurrency".

But "future" is well known, widely adopted (though, in different ways)
concurrency primitive.
It definitely has right to be part of "language for concurrency".
(ohhh, three lines of text with "concurrency" in... sorry for that)

I've already implemented Futures as library code several times, but
they are redundant.
To build Future as a library code, you need:
- redundant interface{}
- redundant Mutex
- you still need 'chan'
- you need to wrap it in a struct
- and then provide "convenient" redundant api.

But 99% of functionality is already in 'chan' implementation.
And ":= <-" with "<-" is a perfect api for future.
There is a need only in a (relatively) small change to runtime and (a
bit larger) to compiler.


понедельник, 17 октября 2016 г., 16:42:17 UTC+3 пользователь 
adon...@google.com написал:
>
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>> It could be implemented in a library, using mutex, channel and interface.
>> Example: 
>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>>  
>> 
>>
>
> If it can be implemented as a library, why build it in to the language? 
>  You don't need futures very often---far less than, say, Mutex, and mutexes 
> aren't built into the language either.
>
>

-- 
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] Hosting Vanity imports on your Hugo static HTML blog

[Nate Finch]

Have a hugo blog?  Want to give your go packages a custom import url (e.g. 
 import "npf.io/gorram/run")?  You can do it with just a few lines of 
templates / frontmatter.

It took some figuring out to get this working, but once you know how to do 
it, it's pretty easy.

https://npf.io/2016/10/vanity-imports-with-hugo/

(note, the part about using a template for aliases for subpackages only 
works with latest master of Hugo, it didn't make it into release 0.17).

-- 
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] Proposal: add "future" internal type (similar to channel)

[Konstantin Khomoutov]

On Sun, 16 Oct 2016 05:40:32 -0700 (PDT)
Sokolov Yura  wrote:

> "future" is commonly used synchronization abstraction.
> 
> It could be implemented in a library, using mutex, channel and
> interface. Example:
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
> 
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value.
> And "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
> 
> So I propose to introduce "future" as a same internal type as a
> "channel". It will share representation and lot of code with buffered
> channel (of capacity 1).
> 
> https://github.com/golang/go/issues/17466

If I'm not mistaken, you propose to implement some abstraction atop of
the existing sync.Cond type.

I'm not sure this is needed: a library implementing a "future" type
will be like 50 lines of code -- basically combining a variable of type
sync.Cond with a variable of type interface{} plus small amount of glue
code.

-- 
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: Proposal: add "future" internal type (similar to channel)

[Roberto Zanotto]

I missed the chance to comment on github...

This also works for implementing futures and it's simple, type-safe and can 
be used with select:
https://play.golang.org/p/VDT36rC5A-
Of course the syntax is not as nice as built-in futures.

On Sunday, October 16, 2016 at 2:40:32 PM UTC+2, Sokolov Yura wrote:
>
> "future" is commonly used synchronization abstraction.
>
> It could be implemented in a library, using mutex, channel and interface.
> Example: 
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value. And 
> "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
>
> So I propose to introduce "future" as a same internal type as a "channel".
> It will share representation and lot of code with buffered channel (of 
> capacity 1).
>
> https://github.com/golang/go/issues/17466
>

-- 
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: Proposal: add "future" internal type (similar to channel)

[Viktor Kojouharov]

A future is just a special case of an observable.  Honestly I'd prefer if 
an observable was built-in the language like a channel. You could use it 
like a channel in selects and the like, but with the possibility of 
receiver observables to be closable. When the list receiver observable is 
closed, the sender could stop producing new values.

On Sunday, October 16, 2016 at 3:40:32 PM UTC+3, Sokolov Yura wrote:
>
> "future" is commonly used synchronization abstraction.
>
> It could be implemented in a library, using mutex, channel and interface.
> Example: 
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value. And 
> "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
>
> So I propose to introduce "future" as a same internal type as a "channel".
> It will share representation and lot of code with buffered channel (of 
> capacity 1).
>
> https://github.com/golang/go/issues/17466
>

-- 
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] Centos - golang 1.6/1.7 - dial tcp i/o timeout

[roberto . devet]

Is there a way in Golang to cache the response from the DNS server? Java 
apps by default cache the DNS info until the app gets restarted.

On Sunday, October 16, 2016 at 5:01:44 PM UTC-5, Ian Lance Taylor wrote:
>
> On Sun, Oct 16, 2016 at 9:10 AM,   
> wrote: 
> > 
> > Getting dail tcp error while calling httpClient.Get or httpClient.Post 
> > 
> > 
> > http client settings: 
> > httpClient = { 
> > Timeout: 30 * time.Second, 
> > } 
> > 
> > Error: 
> > 
> > dial tcp: lookup on xx.xx.xx.xxx:53: dial udp xx.xx.xx.xxx:53: i/o 
> timeout 
> > 
> > 
> > CentOS version: CentOS Linux release 7.2.1511 (Core) 
> > 
> > 
> > can you provide the resolution for this? 
>
> Looks like your DNS server is not responding to your Go program.  Any 
> idea why?  Firewall issue?  Misunderstanding of DNS config files?  You 
> could try setting `GODEBUG=netdns=cgo` in the environment; see 
> https://golang.org/pkg/net. 
>
> 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: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь 
adon...@google.com написал:
>
>
> Go does not take a strong Erlang-like stance against concurrency with 
> shared variables, so mutexes really are critical to Go's concurrency.
>

Am I mistaken? Golang authors said mutexes are second class citizens.
They'd prefer not to expose them, but unfortunately, channels are not fast 
enough for some use-cases.
 

> This is really a special case of the argument for generics in Go.
>
> Futures are to channels and stacks are to slices.  With generics, you 
> could provide first-class Future and Stack, but without generics it's 
> simply not worth the effort for most users to bother with the abstraction 
> since it can be written in little more than a dozen lines of code:  
> https://play.golang.org/p/Obqag2hgZe  It's just easier to implement the 
> underlying operations directly.
>

Your code also misses the case when concurrently running goroutines wish to 
fill same future.
That is why I think it should be at least in standard library, but better 
in a language: it should be reliable, and not error-prone.
 

> Adding a new data type is not a small change to the language.  It requires 
> changes to the spec, the compiler, the reflect package, every program that 
> uses the reflect package, every tool that manipulates Go source code, and 
> many other things too.  The only types that currently enjoy special status 
> in the type system are slice, map, channel and a small number of others, 
> all of which are very widely used.
>

Most uses of reflect package doesn't bother with synchronization 
primitives. They only detects structs, strings, maps and slices, and 
ignores rest.
Most of such code will not be broken.

But I agree with you (or better said: you caught me): I cheated a bit when 
were talking about amount of changes.
That is bonus point for you, cause you first who said about it.

-- 
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: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto 
Zanotto написал:
>
> I missed the chance to comment on github...
>
> This also works for implementing futures and it's simple, type-safe and 
> can be used with select:
> https://play.golang.org/p/VDT36rC5A-
> Of course the syntax is not as nice as built-in futures.
>

Roberto, no it doesn't work.
You miss possibility of filling future from several (usually, two) 
concurrently running goroutines.

>

-- 
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] output files from build of swig file

[Ian Lance Taylor]

On Mon, Oct 17, 2016 at 4:11 AM,   wrote:
>
> I have a follow-up question, how can I instrument my go code so that I can
> set the include path that is used to resolve '%include' statements in my
> swig code. Currently I have relative paths in my swig file, and I would like
> to put '/usr/include' on the search path for the swig compilation. Is this
> possible?

There is no general support for passing arguments to SWIG, but any -I
options found in the CGO_CFLAGS environment variable (see
https://golang.org/cmd/cgo) will be passed to SWIG.

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: Proposal: add "future" internal type (similar to channel)

['Alan Donovan' via golang-nuts]

On 17 October 2016 at 12:31, Sokolov Yura  wrote:
>
> понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь
> adon...@google.com написал:
>>
>> Go does not take a strong Erlang-like stance against concurrency with
>> shared variables, so mutexes really are critical to Go's concurrency.
>>
>
> Am I mistaken? Golang authors said mutexes are second class citizens.
> They'd prefer not to expose them, but unfortunately, channels are not fast
> enough for some use-cases.
>

Well, it's true that mutexes can be implemented in terms of channels,
albeit with some loss of efficiency in practice, so in that sense I suppose
you could describe them as second class.  But it doesn't change the
fundamentals: unlike Erlang, Go has always supported mutable variables
concurrently accessible by multiple goroutines, and I've never heard anyone
in the Go community wish it were otherwise.

Your code also misses the case when concurrently running goroutines wish to
> fill same future.
>

That is true, but it's an advanced feature not needed by most users of
Futures.  You can of course add it at the cost of a few extra lines of
code.  Recall my stack analogy: for most users, it's not worth defining a
new Stack type; a slice will do. But some may want more advanced stack
features and then using a library package might be worth the cost (of
clumsy syntax).


> Most uses of reflect package doesn't bother with synchronization
> primitives. They only detects structs, strings, maps and slices, and
> ignores rest.
> Most of such code will not be broken.
>

A great many programs have a "switch v.Kind()" and a case for every
reflect.Kind.  All such programs would be broken by your change.  If for no
other reason, this means we cannot add Futures to the language because we
have guaranteed not to break any valid Go 1.x program.

-- 
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] output files from build of swig file

[andrew . smith]

Thanks for confirming, I realised this by digging into the go build code. 

// Run SWIG on one SWIG input file.
  3553  func (b *builder) swigOne(p *Package, file, obj string, pcCFLAGS 
[]string, cxx bool, intgosize string) (outGo, outC string, err error) {
  3554  cgoCPPFLAGS, cgoCFLAGS, cgoCXXFLAGS, _, _ := b.cflags(p, true)
  3555  var cflags []string
  3556  if cxx {
  3557  cflags = stringList(cgoCPPFLAGS, pcCFLAGS, cgoCXXFLAGS)
  3558  } else {
  3559  cflags = stringList(cgoCPPFLAGS, pcCFLAGS, cgoCFLAGS)
  3560  }
  3561  
  3562  n := 5 // length of ".swig"
  3563  if cxx {
  3564  n = 8 // length of ".swigcxx"
  3565  }
  3566  base := file[:len(file)-n]
  3567  goFile := base + ".go"
  3568  gccBase := base + "_wrap."
  3569  gccExt := "c"
  3570  if cxx {
  3571  gccExt = "cxx"
  3572  }
  3573  
  3574  _, gccgo := buildToolchain.(gccgoToolchain)
  3575  
  3576  // swig
  3577  args := []string{
  3578  "-go",
  3579  "-cgo",
  3580  "-intgosize", intgosize,
  3581  "-module", base,
  3582  "-o", obj + gccBase + gccExt,
  3583  "-outdir", obj,
  3584  }
  3585  
  3586  for _, f := range cflags {
  3587  if len(f) > 3 && f[:2] == "-I" {
  3588  args = append(args, f)
  3589  }
  3590  }
  3591  
  3592  if gccgo {
  3593  args = append(args, "-gccgo")
  3594  if pkgpath := gccgoPkgpath(p); pkgpath != "" {
  3595  args = append(args, "-go-pkgpath", pkgpath)
  3596  }
  3597  }
  3598  if cxx {
  3599  args = append(args, "-c++")
  3600  }
  3601  
  3602  out, err := b.runOut(p.Dir, p.ImportPath, nil, "swig", args, 
file)
  3603  if err != nil {
  3604  if len(out) > 0 {
  3605  if bytes.Contains(out, []byte("-intgosize")) || 
bytes.Contains(out, []byte("-cgo")) {
  3606  return "", "", errors.New("must have 
SWIG version >= 3.0.6")
  3607  }
  3608  b.showOutput(p.Dir, p.ImportPath, 
b.processOutput(out)) // swig error
  3609  return "", "", errPrintedOutput
  3610  }
  3611  return "", "", err
  3612  }
  3613  if len(out) > 0 {
  3614  b.showOutput(p.Dir, p.ImportPath, b.processOutput(out)) 
// swig warning
  3615  }
  3616  
  3617  return obj + goFile, obj + gccBase + gccExt, nil
  3618  }




On Monday, October 17, 2016 at 5:50:44 PM UTC+1, Ian Lance Taylor wrote:
>
> On Mon, Oct 17, 2016 at 4:11 AM,   
> wrote: 
> > 
> > I have a follow-up question, how can I instrument my go code so that I 
> can 
> > set the include path that is used to resolve '%include' statements in my 
> > swig code. Currently I have relative paths in my swig file, and I would 
> like 
> > to put '/usr/include' on the search path for the swig compilation. Is 
> this 
> > possible? 
>
> There is no general support for passing arguments to SWIG, but any -I 
> options found in the CGO_CFLAGS environment variable (see 
> https://golang.org/cmd/cgo) will be passed to SWIG. 
>
> 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] High CPU usage for process using mdns (Flame graph attached) - time spent in runtime.goexit and runtime.mstart

[Abhay Bothra]

We are using Hashicorp's mdns library (https://github.com/hashicorp/mdns) 
for node discovery, with a frequency of 1 mdns query / minute. The CPU 
consumption by the process increases very gradually over a couple of days, 
going from 2-3% to 20-30% over 3-4 days. From the runtime instrumentation 
we have done, the number of go-routines seems to be fairly static.

The attached flame-graph from the pprof output suggests that a log of CPU 
is being spent on runtime.goexit and runtime.mstart. To me this seems to 
suggest that we are starting very short lived go-routines.
- Is it fair to blame lots of short-lived go-routines for this?
- What else can lead to this sort of behavior?
- How should be go about instrumenting our code in order to be able to get 
a root cause?

Really appreciate any help.

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

[go-nuts] Currently Hiring for GoLang/XML Developer in Denver

[Andrea Biegalski]

I'm currently looking for a developer to join one my largest clients in 
Downtown Denver, CO. 

This team handles strategic short projects

Specific targeted gap - video distribution team

They are building a product for video stream infrastructure

 

*Looking for a *

Golang developer - automation and verification of new application

1 year xml development in background mpeg dash

video background preferred not required

Some with networking application development background preferred  with 
experience in TCPIP connections/ mpeg 2 transport 

familiarity with HTTP live stream

Some amount of QA would be good

minimum 1 year of Go 

Java background - but no constraint will entertain anyone with Golang 
development experience 

Candidate will only focus on development and design

 

*Interview process:*

2 phone screen

1 In person (I can arrange travel)

some coding exercise


If you are interested or would like to refer someone for the position 
please email me at andrea.biegal...@artechinfo.com

Pay rate is very good!

-- 
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: Serialization internal data to disk

[Gulácsi Tamás]

No, method 1 preserves "err" if it is not nil.

Tong Sun  ezt írta (időpont: 2016. okt. 17., H 20:11):

>
> On Mon, Oct 17, 2016 at 1:20 AM, Tamás Gulácsi wrote:
>
>
>
> The reason that I didn't do it, is because I don't know how to do it. In
> essence, that "f.Close()" that you worried about is wrapped in "defer
> f.Close()" in SaveState, which in turn wrapped in "defer SaveState" in a
> function. I.e., all is happening during the program tear-down phase. If we
> are not planting a "log.Fatal(err)" bomb in SaveState itself, how do you
> think we should check it properly?
>
>
> There are several possibilities. Two easy:
> 1. use a named return parameter:
> func SaveState(...) (err error) {
> ...
> // close the file and return the error
> defer func() {
>   if closeErr := f.Close(); closeErr != nil && err == nil {
> err = closeErr
> }()
> ...
> }
>
>
> That method will interfere with/overwrite the existing return logic right?
>
> Basically, my "func SaveState(...) error" has "return gob.NewEncoder(f).
> Encode(state)" as the last statement:
>
> func SaveState(persistName string, state interface{}) error {
> // create persistence file
> f, err := os.Create(persistName)
> if err != nil {
> return err
> }
> defer f.Close()
> // write persistemce file
> err = gob.NewEncoder(f).Encode(state)
> return err
> }
>
> if using the method 1, then if the gob.NewEncoder(f).Encode(state) fails,
> but defer f.Close() works, the true error will be lost, right?
>
>
> 2. Treat the defer f.Close() just as a resource releaser for error path,
> and do an "return f.Close()" anyway:
> func SaveState(...) error {
> ...
> defer f.Close() // just release resources on error paths
> ...
> return f.Close() // never lose the error of Close!
> }
>
> yes, this does call f.Close() twice, and the second (the defer) will error
> out, but that does no harm.
>
>
> OK, will try to do that, and report back...
>
>

-- 
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] simplifying freeing CString

[andrew . smith]

Hi,

When using cgo its my understanding that strings created with C.CString 
must be freed with C.free, but yet numeric types do not need to be 
explicitly freed.

Firstly, is CString a special case here, or are there other types that need 
to be explicitly freed as well?

Secondly, Im writing a lot of wrappers to cgo functions that will requiring 
converting go 'string' arguments in the outer function, into C.String 
arguments in the cgo inner function. Im looking for a simple way to ensure 
that I dont create any memory leaks. In view of this I have an idea to wrap 
the CString in a go struct and set the finalizer to free the CString :

// -- wrapped.go 
--

package golasso

import (
// #include 
"C"
"fmt"
"runtime"
"unsafe"
)

type WrappedString struct {
s *C.char
}

func FreeWrappedString(s *WrappedString) {
fmt.Print("Freeing WrappedString")
C.free(unsafe.Pointer(s.s))
}

func NewWrappedString(s string) WrappedString {
wrappedString := WrappedString{s: C.CString(s)}
runtime.SetFinalizer(, FreeWrappedString)
return wrappedString
}


// --

func simulatedCCall(s *C.char) {

fmt.Print("simulated C call")

}

// -- wrapped_test.go 
--
package golasso

import (
"runtime"
"testing"
)

func TestWrapped(t *testing.T) {
simulatedCCall(NewWrappedString("fred").s)
t.Logf("simulated C call")
runtime.GC()
}






NB: I do realise that, in a production scenario, it might be a long time 
before the GC runs and therefore a long time before the GC calls the 
finalizer to free the CString. Im not so worried about this, as my primary 
concern is ensuring that *every* CString is definitely going to be freed at 
some point, and therefore I have no *true* memory leaks.

What are the pros/cons of this? Is it even correct? Is there an easier way 
to achieve this?

Andy

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