Re: [go-nuts] P-local/M-local storage for goroutines?

My use case is a little bit complicated. The goroutine are running some user-defined applications, and they might concurrently access the same os file. Also, I cannot limit the number of goroutines because I cannot control the user code. I tried to evaluate the performance with lru & without

Re: [go-nuts] P-local/M-local storage for goroutines?

Thanks for the link. I just find built-in sync.Pool, but it does not fit into my requirement. sync.Pool lends objects to application and expects them to return. But I would like to give objects to local storage and query the object later. Is there anything like a variant of sync.Pool? 在

Re: [go-nuts] Re: prevent alteration of binaries once distributed in the wild?

Don't be too afraid of governments tampering with your program, I mean this in the best possible way, but you are nobody important enough :) Governments issue subpoenas, arrest warrants, and issue court orders - that's much quicker and more effective than hacking. In the security space, we also

Re: [go-nuts] P-local/M-local storage for goroutines?

Instead of starting new goroutines, send requests to existing goroutines via a channel. In effect you are simulating an N core processor with per code local caches and one shared cache so you can look at how processors manage cache. Just create N goroutines at the start and profile to see what

Re: [go-nuts] P-local/M-local storage for goroutines?

https://github.com/davecheney/junk/tree/master/id but see the warnings. Still, I would use mutex and shared caches until you can prove that the costs matter before resorting to the library. You might be interested in

[go-nuts] Re: P-local/M-local storage for goroutines?

Actually, I am trying to manage the memory. Segment-based solution is indeed convenient, but the merging of adjacent segments becomes an inconvenience for me now. For example, I would like to reclaim only a 2M chunk, but the auto-merging of segments finally creates a huge segment of size 64M..

Re: [go-nuts] P-local/M-local storage for goroutines?

CGO sounds good, but I remember CGO invocation is not cheap? (not sure where I saw it). Would you provide a reference to "Chaney id project"? I don't find much information about it. I will look into the named goroutine discussion. Thanks. 在 2019年7月24日星期三 UTC+8上午1:52:35，Robert Engels写道： > >

Re: [go-nuts] P-local/M-local storage for goroutines?

Thanks for the example code, this is a possible solution. But my goroutine is not long-running. More specifically, each goroutine performs some IO, then returns. Next time, there might be another goroutine accessing the same file. One workaround is to return the local storage back to

Re: [go-nuts] time.Format vs. fmt.Sprintf

Dan is the only one in this thread who pays attention to the actual value of the timestamp not just to its format :-) --Leo On Tuesday, July 23, 2019 at 7:45:37 PM UTC-4, Robert Engels wrote: > > Funny. Did you remember it or just pay close attention to these things? > > > On Jul 23, 2019, at

Re: [go-nuts] time.Format vs. fmt.Sprintf

I couldn't find the thread in my go-nuts box, so I looked for it on google groups. Chris, it may be relevant, but the thread is stale and so the conversation is unlikely to be productive, particularly if people don't have the previous comments that led up to this reanimation. On Tue, 2019-07-23

Re: [go-nuts] time.Format vs. fmt.Sprintf

Funny. Did you remember it or just pay close attention to these things? > On Jul 23, 2019, at 6:38 PM, Dan Kortschak wrote: > > This thread is 7 years old. > >> On Tue, 2019-07-23 at 12:03 -0700, chrishornber...@gmail.com wrote: >> Sometimes projects have upstream requirements that you can't

[go-nuts] Re: prevent alteration of binaries once distributed in the wild?

thanks to everyone for sharing its thoughts about this question. it confirms what i read elsewhere. this app is to install on the end user computer, and there is no central authority required to use its service.Unlike the game Michael Jones is working on, where somehow the user must to connect

Re: [go-nuts] time.Format vs. fmt.Sprintf

I will add that high performance logging is a requirement of most financial applications - although usually it is a binary format that is "pretty formatted" later for archival/searching, sometimes on demand.-Original Message- From: chrishornber...@gmail.com Sent: Jul 23, 2019 2:03 PM To:

Re: [go-nuts] time.Format vs. fmt.Sprintf

Sometimes projects have upstream requirements that you can't change, avoid, or redefine. Sometimes you don't have a choice in how or what data you're providing downstream to other consumers. On Thursday, April 5, 2012 at 3:24:09 PM UTC-4, Russ Cox wrote: > > Maybe you should look into why you

[go-nuts] Re: P-local/M-local storage for goroutines?

On Tuesday, July 23, 2019 at 1:22:09 PM UTC-4, Zihan Yang wrote: > > I am trying to implement an LRU cache. > Don't use an LRU, use a working set cache. Proven to be better back in 1969 by Peter J Denning. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: prevent alteration of binaries once distributed in the wild?

On Tuesday, July 23, 2019 at 2:51:27 PM UTC-4, clement auger wrote: > > I m looking for a technique to prevent binary alteration once distributed > in the wild. > This is impossible. You can make it harder, you can detect it, but as long as we use a Von Neumann architecture, executable code is

Re: [go-nuts] prevent alteration of binaries once distributed in the wild?

One more thought ... just to expand your thinking beyond the excellent responses already given, is to rephrase the goal as "how do I prevent a modified binary (executable) from causing problems?" This is a weaker goal but can in some contexts be more manageable. I can't share full details, but

Re: [go-nuts] prevent alteration of binaries once distributed in the wild?

On Tue, Jul 23, 2019 at 11:51 AM clement auger wrote: > Hi, > > I m looking for a technique to prevent binary alteration once distributed > in the wild. > > I have no clue what i m asking for. > The best current solutions are package manager oriented. Decide on the platform you want to work on

Re: [go-nuts] prevent alteration of binaries once distributed in the wild?

The signature would probably be computed only over data segments (or equivalent) in the executable file format, and stored outside of those sections. This approach doesn't work when the person with the binary can write to the binary (which is usually always). They can just change the signature to

[go-nuts] prevent alteration of binaries once distributed in the wild?

Hi, I m looking for a technique to prevent binary alteration once distributed in the wild. I have no clue what i m asking for. I was imagining a solution where a signature is prepended to the binary and checked during the startup sequence. However i do understand (well ... i imagine it) the

Re: [go-nuts] P-local/M-local storage for goroutines?

Also, you will probably fine that a multi level mutex based solution will perform fine. The Go lightweight threads make this very efficient. The sync.Map may help as well but it has some performance issues. > On Jul 23, 2019, at 12:52 PM, Robert Engels wrote: > > You will need to use CGo.

Re: [go-nuts] P-local/M-local storage for goroutines?

You will need to use CGo. See Chaney “id” project for ideas. Since the underlying OS threads are shared and will not be switched while in the C code it is fairly straightforward but having a robust typed cache will be problematic. There are discussions on golang-dev about named Go routines

Re: [go-nuts] P-local/M-local storage for goroutines?

The simple, common way--if I understand you need correctly--is to launch a method goroutine. type CacheManager struct { // things a worker needs to know, such as the global cache, the specific worker's local cache, etc. } func master() { for i := 0; i < workers; i++ { m := new(CacheManager)

Re: [go-nuts] Re: Preparing defaults for multiple-values-returning functions

That’s my feeling. Bare returns are not good. The easiest and most readable solution to the OPs problem and not using bare returns is labeled exits. Local functions quickly become unwieldy when multiple are required IMO. > On Jul 23, 2019, at 11:03 AM, jake6...@gmail.com wrote: > >> On

[go-nuts] Re: Preparing defaults for multiple-values-returning functions

(Previous post deleted to to premature "Post") My 2 cents. I'm a seasoned Go programmer with years of professional Go experience, and decades of coding work. Personally, I would avoid goto if possible. It may "have been a best practice for a long time" in C/C++ and other languages. But in Go,

[go-nuts] Re: Preparing defaults for multiple-values-returning functions

On Monday, July 22, 2019 at 2:51:43 PM UTC-4, Tong Sun wrote: > > I want to define a default set of values for the multiple-values-returning > function, so when doing error checking along the way, I can return such > default set when things go wrong. > > How can I do that? > Is it possible to

[go-nuts] Re: Need help to learn go lang

Em sexta-feira, 19 de julho de 2019 10:39:03 UTC-3, veeres...@gmail.com escreveu: > > would anyone help me out how to learn go lang more practically , may be > some resources . I want to understand go lang more practically , with some > great examples. > > thank you! > If you have basic

Re: [go-nuts] Preparing defaults for multiple-values-returning functions

I prefer to define a local func that returns the default values. https://play.golang.org/p/UOPdouwoy0v (Moreover you should avoid using `else` behind `return`) Le lundi 22 juillet 2019 21:08:53 UTC+2, Robert Engels a écrit : > > Depends on the length of the function, and number of