Re: [go-nuts] Is there a way to check if all pending finalizers have been executed?

[digg]

On Saturday, October 15, 2016 at 6:37:08 PM UTC+8, Hotei wrote:
>
> re "meaningfullness" - I think he's saying that a finalizer for a function 
> called in a goroutine might not run if main() quits first, intentionally or 
> otherwise.  You can of course check for this specific case by making sure 
> all your goroutines are cleaned up before exiting main - but in some 
> (many?) cases that's overkill. 
>
>  If it's REALLY important to know which finalizer actions completed you 
> could log them to disk and analyse the results afterwards to see that all 
> the boxes got checked. Not quite what the OP was looking for I know - but 
> might help diagnose problems.  
>


Can you enum any use cases of SetFinalizer 
? I mean the 
use cases where alternative solutions would do worse than SetFinalizer 
.
 

>
> On Saturday, October 15, 2016 at 3:08:46 AM UTC-4, di...@veryhaha.com 
> wrote:
>>
>>
>>
>> On Saturday, October 15, 2016 at 8:18:04 AM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Fri, Oct 14, 2016 at 4:08 PM, 'Peter Lam' via golang-nuts 
>>>  wrote: 
>>> > Is there someway to wait for all pending finalizers to be run? 
>>>
>>> Not in general, no.  Conceptually it doesn't make sense since, as you 
>>> know, finalizers not guaranteed to run at all.  You could of course 
>>> write your finalizers to support this. 
>>>
>>> Ian 
>>>
>>
>> if finalizers not guaranteed to run at all, then what is its 
>> meaningfulness? 
>>
>

-- 
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: Duplicate File Checker Performance

[Sri G]

Thanks. Made the go code similar to python using CopyBuffer with a block 
size of 65536. 

buf := make([]byte, 65536)

if _, err := io.CopyBuffer(hash, file, buf); err != nil {
fmt.Println(err)
}

Didn't make too much of a difference, was slightly faster.

What got it to the same place was running ComputeHash in the same goroutine 
as the Walk function vs its own go routine for each file

+ComputeHash(path, info, queue, wg)
-go ComputeHash(path, info, queue, wg)


*2.88s user 0.98s system 23% cpu 16.086 total, memory usage ~ 7MB*

Here's the before and after pprof webs:

BEFORE with 'go ComputeHash(...):




AFTER with 'ComputeHash(...):




Since disk read are SOO much slower, computing the hash for each file in 
its own goroutine caused a huge slowdown.. 

btw this is on a RAID10, with SSD: 

Old code SSD: 3.31s user 17.87s system 244% cpu 8.667 total

New code SDD:* 2.88s user 0.84s system 69% cpu 5.369 total*

Shows you can throw hardware at a problem BUT the old code locks up my 
system momentarily..


On Saturday, October 15, 2016 at 3:27:38 PM UTC-4, Kevin Malachowski wrote:
>
> Sorry, I meant that calling Write on the hash type might be slower if it's 
> called more often.
>
> (I'm on mobile right now. When I get back to a keyboard I'll try to come 
> up with an example)
>

-- 
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 Sat, Oct 15, 2016 at 5:52 PM, Justin Israel wrote:

>
>
> On Sun, 16 Oct 2016, 8:17 AM Tong Sun wrote:
>
>> Hi,
>>
>> Need help again.
>>
>> I got everything tested out correctly, in https://github.com/suntong/
>> lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go, but when I tried
>> to apply it to my real case (more complicated data structure), it doesn't
>> work any more. I've put my code at,
>>
>> http://gopkg.in/suntong/deduper.v1
>> i.e., https://github.com/suntong/deduper/tree/v1.2
>>
>> Here is the relevant piece:
>>
>>  mh := minhash.New(cfg.bands, cfg.rows, cfg.shingles)
>>  persistName := "mh.gob"
>>  RestoreState(persistName, mh)
>>  defer SaveState(persistName, mh)
>>
>>
>> The same code works well in https://github.com/suntong/
>> lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go, but in
>> my deduper.v1, after the program is run, that "defer SaveState" should
>> have saved something, but the mh.gob is still an empty file:
>>
>> $ ls -l mh.gob
>> -rw-rw 1 tong tong *22* 2016-10-15 15:13 mh.gob
>>
>> What might be the cause?
>> How to fix it?
>>
>
> You don't seem to check for errors in your restore and save calls. How do
> you know that your save is actually working?
>

That's a good point, still not the true cause -- checking them will be a
good practice, but will not solve the problem here, because the exact same
code works in
https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go.
I've verify from the code and result that the save *is* actually working.

-- 
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: Duplicate File Checker Performance

[Sri G]

Too diagnose this issue, I tried some benchmarks with time tested tools:

On the same directory:

find DIR -type f -exec md5 {} \; 

*5.36s user 2.93s system 50% cpu 16.552 total*

Adding a hashmap on top of that wouldn't significantly increase the time.

Making this multi-processed (32 processes): 

find DIR -type f -print0 | xargs -0 -n 1 -P 32 md5

*5.32s user 3.24s system 43% cpu 19.503 total*

With 64 processes, like GOMAXPROCS=64 on this machine.

find DIR -type f -print0 | xargs -0 -n 1 -P 64 md5


*5.31s user 3.66s system 42% cpu 20.999 total*
So it seems disk access is the bottleneck as it should be and the biggest 
performance hit comes from the synchronization

I wrote a python script to do the same, code is 
here: https://github.com/hbfs/dupe_check/blob/master/dupe_check.py

*2.97s user 0.92s system 24% cpu 15.590 total, memory usage is ~ 8MB*

My next step is to try a single threaded/goroutine version in Go to 
replicate this level of performance and get a deeper understand of how Go 
is built and how to use it more effectively. Advice appreciated!

On Saturday, October 15, 2016 at 5:15:29 AM UTC-4, Sri G wrote:
>
> I wrote a multi-threaded duplicate file checker using md5, here is the 
> complete source: 
> https://github.com/hbfs/dupe_check/blob/master/dupe_check.go
>
> Benched two variants on the same machine, on the same set of files (~1.7GB 
> folder with  ~600 files, each avg 3MB), multiple times, purging disk cache 
> in between each run.
>
> With this code:
>
> hash := md5.New()
>
> if _, err := io.Copy(hash, file); err != nil {
>   fmt.Println(err)
> }
>
> var md5sum [md5.Size]byte
> copy(md5sum[:], hash.Sum(nil)[:16])
>
> *// 3.35s user 105.20s system 213% cpu 50.848 total, memory usage is ~ 
> 30MB*
>
>
> With this code:
>
>   data, err := ioutil.ReadFile(path)
>   if err != nil {
> fmt.Println(err)
>   }
>
>   md5sum := md5.Sum(data)
>
> * // 3.10s user 31.75s system 104% cpu 33.210 total, memory usage is ~ 
> 1.52GB*
>
> The memory usage make sense, but why is the streaming version ~3x slower 
> than the read the entire file into memory version? This trade off doesn't 
> make sense to me since the file is being read from disk in both situations 
> which should be the limiting factor. Then the md5sum is being computed. 
>
> In the streaming version, there is an extra copy from []byte to [16]byte 
> but that should be negligible.
>
> My only theory I can think of is context switching
>
> streaming version:
> disk -> processor
> processor waiting for disk read so it switch to read another file, 
> sleeping the thread.
>
> entire file:
> disk -> memory -> processor
> file is in memory so not as much context switching.
>
> What do you think? 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.

Re: [go-nuts] Re: Serialization internal data to disk

[Justin Israel]

On Sun, 16 Oct 2016, 8:17 AM Tong Sun  wrote:

> Hi,
>
> Need help again.
>
> I got everything tested out correctly, in
> https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go,
> but when I tried to apply it to my real case (more complicated data
> structure), it doesn't work any more. I've put my code at,
>
> http://gopkg.in/suntong/deduper.v1
> i.e., https://github.com/suntong/deduper/tree/v1.2
>
> Here is the relevant piece:
>
>  mh := minhash.New(cfg.bands, cfg.rows, cfg.shingles)
>  persistName := "mh.gob"
>  RestoreState(persistName, mh)
>  defer SaveState(persistName, mh)
>
>
> The same code works well in
> https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go,
> but in my deduper.v1, after the program is run, that "defer SaveState"
> should have saved something, but the mh.gob is still an empty file:
>
> $ ls -l mh.gob
> -rw-rw 1 tong tong *22* 2016-10-15 15:13 mh.gob
>
> What might be the cause?
> How to fix it?
>

You don't seem to check for errors in your restore and save calls. How do
you know that your save is actually working?


> Thanks
>
> On Sunday, February 7, 2016 at 10:18:16 PM UTC-5, Tong Sun wrote:
>
>
> On Sunday, February 7, 2016 at 8:29:29 PM UTC-5, Michael Jones wrote:
>
> ha ha! I was typing the same thing. Matt types faster. ;-)
>
>
> Thank you both!
>
> --
> 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] regexp with ^

[Marvin Stenger]

Thanks, worked.

Am Samstag, 15. Oktober 2016 22:16:14 UTC+2 schrieb Shawn Milochik:
>
> Escape the carat with the backslash.
>
> https://play.golang.org/p/SX_q0KuIvU
>

-- 
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] regexp with ^

[Shawn Milochik]

 Escape the carat with the backslash.

https://play.golang.org/p/SX_q0KuIvU

-- 
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] regexp with ^

[Marvin Stenger]

Hello,

I have the problem, that I want to match expressions like:

bar_f00^42

, but "[[:alpha:]]+_[[:alnum:]]+^[[:digit:]]+" won't work because of the 
'^'.

So what are my options?

Best,
Marvin

-- 
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 Sat, Oct 15, 2016 at 3:17 PM, Tong Sun wrote:

> I've put my code at,
>
> http://gopkg.in/suntong/deduper.v1
> i.e., https://github.com/suntong/deduper/tree/v1.2
>

FTA, README updated, see https://github.com/suntong/deduper/tree/trim

-- 
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] Duplicate File Checker Performance

['Kevin Malachowski' via golang-nuts]

Sorry, I meant that calling Write on the hash type might be slower if it's 
called more often.

(I'm on mobile right now. When I get back to a keyboard I'll try to come up 
with an example)

-- 
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] Duplicate File Checker Performance

['Kevin Malachowski' via golang-nuts]

It also might be inefficient to call Sum multiple times with smaller slices 
compared to calling it once with a larger slice. Try using io.CopyBuffer and 
passing in larger buffer sizes to see if the CPU and memory usage start to 
converge.

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

Hi, 

Need help again. 

I got everything tested out correctly, 
in 
https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go,
 
but when I tried to apply it to my real case (more complicated data 
structure), it doesn't work any more. I've put my code at, 

http://gopkg.in/suntong/deduper.v1 
i.e., https://github.com/suntong/deduper/tree/v1.2

Here is the relevant piece:

 mh := minhash.New(cfg.bands, cfg.rows, cfg.shingles)
 persistName := "mh.gob"
 RestoreState(persistName, mh)
 defer SaveState(persistName, mh)


The same code works well in 
https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go,
 
but in my deduper.v1, after the program is run, that "defer SaveState" 
should have saved something, but the mh.gob is still an empty file:

$ ls -l mh.gob 
-rw-rw 1 tong tong *22* 2016-10-15 15:13 mh.gob

What might be the cause? 
How to fix it? 

Thanks

On Sunday, February 7, 2016 at 10:18:16 PM UTC-5, Tong Sun wrote:
>
>
> On Sunday, February 7, 2016 at 8:29:29 PM UTC-5, Michael Jones wrote:
>>
>> ha ha! I was typing the same thing. Matt types faster. ;-)
>>
>
> Thank you both! 
>

-- 
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] Is there a way to check if all pending finalizers have been executed?

[Dave Cheney]

You shouldn't rely on finalisers for the correctness of your program, which is 
another way of saying, you shouldn't rely on finalisers. Period. 

-- 
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: High memory usage of math/big.putNat for web application

[alb . donizetti]

Does this happens on tip too? There was a recent CL that
modified the code of the nat pool; see

https://go-review.googlesource.com/#/c/30613/

exp. the "Eliminate allocation in divLarge nat pool" part.


Il giorno sabato 15 ottobre 2016 16:28:01 UTC+2, Raffaele Di Fazio ha 
scritto:
>
> Hi, 
> I have a web application that over time uses more and more memory. This is 
> the output of pprof of the heap: 
>
> go tool pprof -alloc_space lushan-server https:
> //localhost:8083/debug/pprof/heap
> Fetching profile from https://localhost:8083/debug/pprof/heap
> Saved profile in /Users/rdifazio/pprof/pprof.lushan-server.localhost:
> 8083.alloc_objects.alloc_space.022.pb.gz
> Entering interactive mode (type "help" for commands)
> (pprof) top
> 43.06MB of 67.07MB total (64.20%)
> Dropped 4 nodes (cum <= 0.34MB)
> Showing top 10 nodes out of 188 (cum >= 1.50MB)
>   flat  flat%   sum%cum   cum%
>   26MB 38.76% 38.76%   26MB 38.76%  math/big.putNat
>3MB  4.48% 43.24% 3.50MB  5.22%  encoding/json.(*decodeState).
> objectInterface
> 2.50MB  3.73% 46.97% 2.50MB  3.73%  crypto/tls.(*Conn).write
>2MB  2.98% 49.96%2MB  2.98%  crypto/tls.(*block).reserve
>2MB  2.98% 52.94%10.50MB 15.66%  encoding/json.Unmarshal
> 1.55MB  2.31% 55.25% 1.55MB  2.31%  regexp.(*bitState).reset
> 1.50MB  2.24% 57.49% 9.50MB 14.17%  github.com/go-openapi/spec.(*
> Schema).UnmarshalJSON
> 1.50MB  2.24% 59.72%27.50MB 41.00%  math/big.nat.divLarge
> 1.50MB  2.24% 61.96% 5.50MB  8.20%  math/big.nat.expNN
> 1.50MB  2.24% 64.20% 1.50MB  2.24%  crypto/sha512.New384
> (pprof)
>
>
> ROUTINE  math/big.putNat in /usr/local/Cellar/go/
> 1.7.1/libexec/src/math/big/nat.go
>   26MB   26MB (flat, cum) 38.76% of Total
>  .  .550: }
>  .  .551: return z.make(n)
>  .  .552:}
>  .  .553:
>  .  .554:func putNat(x nat) {
>   26MB   26MB555: natPool.Put(x)
>  .  .556:}
>  .  .557:
>  .  .558:var natPool sync.Pool
>  .  .559:
>  .  .560:// q = (uIn-r)/v, with 0 <= r < y
>
>
>
> The memory allocated in math/big.putNat seems to increase over time, 
> generating a very high usage of memory for a web applications that is 
> executing very few requests per second. I wonder why and how I can better 
> analyze this issue. Please notice that this happens only when serving 
> HTTPS. 
>
> I'm currently using go 1.7 and the app itself uses the gin web framework. 
>
> Thanks in advance! 
>
> Raffaele 
>

-- 
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: Error handling and structured logging

[Jolie Rouge]

At first I didn't like this idea, but the README has converted me to the 
possibilities. I have to admit I have a strong aversion to interface{}, and 
a map as well, but a lot of the other features are very interesting. I 
think, in a larger project, this may be just the thing for structured 
logging, though I tend to roll my own.

The single mindedness of errors in go is actually something good IMHO, 
though sometimes we'd like to stick more data in, is errors.With("blah", 
"blah").Wrap(other_error) Really different than 
errors.New(fmt.Sprintf("blah=blah because %s",other_err))? I guess it seems 
more pleasing to use a fluid interface if you come to go from a language 
that emphasized that, but sometimes the ease of writing occludes the ease 
of reading, or reasoning. Also - who has time to learn Yet Another Library.

Yet in a large application, say an API or some kind of webservice, 
structured logging and a logging/error API not only has a place, but would 
be a boon to the project all. I think it's a great addition to the 
ecosystem, and good as a tool for people to use if and when they need it. I 
know I'll give it a go on my next project that is a webservice, so this 
might be just the thing...

/Jason

Le mercredi 12 octobre 2016 05:34:48 UTC+2, John Jeffery a écrit :
>
> I have been following the progress of package github.com/pkg/errors, and 
> have put it to much use. Thanks very much to Dave Cheney and the other 
> authors.
>
> A few months ago an interesting issue was raised along the lines of being 
> able to attach arbitrary data to the error (
> https://github.com/pkg/errors/issues/34). Some interesting discussion 
> ensued, and in the end Dave decided not to add this feature to the package, 
> and gave some very good reasons for his decision. This is all good and I 
> think I learned a lot from the discussion.
>
> All the same I became quite interested in the idea that, if key/value 
> pairs of information could be attached to errors as they "bubble up" the 
> stack, then this could provide an alternative to passing a logger down 
> through the call stack, adding context along the way until something 
> actually has to be logged.
>
> So given that the github.com/pkg/errors package was not going to include 
> the feature, I decided to have a go at building an errors package that 
> provides a minimal API for programs that make use of structured logging. 
> The result is at https://github.com/jjeffery/errors. The API has a very 
> small surface area, and I have found it pleasant to use in my own projects.
>
> Of course there are many other popular error handling packages, and 
> github.com/pkg/errors combines the best ideas of many of them. I think it 
> is a stated goal that github.com/pkg/errors be considered for inclusion 
> in the standard library at some point. I just have not seen structured 
> key/values integrated into error handling in quite the same way before, and 
> thought I'd mention this work and ask for community feedback.
>
>

-- 
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 Sun, Feb 7, 2016 at 10:18 PM, Tong Sun wrote:

>
> On Sunday, February 7, 2016 at 8:29:29 PM UTC-5, Michael Jones wrote:
>>
>> ha ha! I was typing the same thing. Matt types faster. ;-)
>>
>
> Thank you both!
>

Just FTA, in case someone searches and finds this,
I've collected all three aforementioned Go Persistent Data w/ GOB Demo code
at,
https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go


// Porgram: PersistentData-GOB.go
// Purpose: Go Persistent Data w/ GOB Demo
// Credits:
//  https://blog.golang.org/gobs-of-data
//  https://play.golang.org/p/wT8_H44crC by Michael Jones
//  Matt Silverlock in go-nuts on "Serialization internal data to
disk"


-- 
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: Create a new instance by TypeOf

[Roberto Zanotto]

Yeah, it's totally fine that way. It's doing reflect.New(CollectorTypeNeed) 
instead 
of reflect.New(CollectorTypeNeed).Elem(), so that the result has 
type *CollectorGoogleAnalytics and can be cast to ICollector.

On Saturday, October 15, 2016 at 6:26:21 AM UTC+2, Paulo Coutinho wrote:
>
> Hi,
>
> I solved it on other group too, a friend help and without remote the 
> pointer. What you think?
>
> https://gist.github.com/prsolucoes/2ebc5f199632ba1d72af11b12891d229
>
> Thanks.
>
> On Friday, October 14, 2016 at 11:26:02 PM UTC-3, Roberto Zanotto wrote:
>>
>> The panic you get is because CollectorGoogleAnalytics does not 
>> implement ICollector, since GetName is defined on type 
>> *CollectorGoogleAnalytics and not CollectorGoogleAnalytics.
>> This works (I changed line 24): https://play.golang.org/p/SIFh3W3qhW
>>
>> On Saturday, October 15, 2016 at 4:02:51 AM UTC+2, Paulo Coutinho wrote:
>>>
>>> Hi,
>>>
>>> I made an example to my problem:
>>> https://play.golang.org/p/zVLH8J7EiP
>>>
>>> But what i need is have some plugins that use an interface to return 
>>> some data. But the plugin is auto inserted in a map of type:
>>> map[string]reflect.TypeOf
>>>
>>> or can be (will be better):
>>> map[string]ICollector
>>>
>>> After get the type by string of map i want create a new instance of it.
>>>
>>> Can anyone help me?
>>>
>>>
>>>

-- 
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] Is there a way to check if all pending finalizers have been executed?

[Hotei]

re "meaningfullness" - I think he's saying that a finalizer for a function 
called in a goroutine might not run if main() quits first, intentionally or 
otherwise.  You can of course check for this specific case by making sure 
all your goroutines are cleaned up before exiting main - but in some 
(many?) cases that's overkill. 

 If it's REALLY important to know which finalizer actions completed you 
could log them to disk and analyse the results afterwards to see that all 
the boxes got checked. Not quite what the OP was looking for I know - but 
might help diagnose problems.  

On Saturday, October 15, 2016 at 3:08:46 AM UTC-4, di...@veryhaha.com wrote:
>
>
>
> On Saturday, October 15, 2016 at 8:18:04 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 14, 2016 at 4:08 PM, 'Peter Lam' via golang-nuts 
>>  wrote: 
>> > Is there someway to wait for all pending finalizers to be run? 
>>
>> Not in general, no.  Conceptually it doesn't make sense since, as you 
>> know, finalizers not guaranteed to run at all.  You could of course 
>> write your finalizers to support this. 
>>
>> Ian 
>>
>
> if finalizers not guaranteed to run at all, then what is its 
> meaningfulness? 
>

-- 
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] Is there a way to check if all pending finalizers have been executed?

[digg]

On Saturday, October 15, 2016 at 8:18:04 AM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Oct 14, 2016 at 4:08 PM, 'Peter Lam' via golang-nuts 
>  wrote: 
> > Is there someway to wait for all pending finalizers to be run? 
>
> Not in general, no.  Conceptually it doesn't make sense since, as you 
> know, finalizers not guaranteed to run at all.  You could of course 
> write your finalizers to support this. 
>
> Ian 
>

if finalizers not guaranteed to run at all, then what is its 
meaningfulness? 

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