Re: [go-nuts] Is there a way to syncronise map reads and writes?

Use a slice instead of a map ? Jason E. Aten a következőt írta (2022. február 23., szerda, 7:10:04 UTC+1): > Unfortunately, that's not how Go maps work. You'll still get races unless > you synchronize even "read-only" maps. > > On Tuesday, February 22, 2022 at 11:59:37 PM UTC-6 ren...@ix.netcom.

[go-nuts] Re: Is there a way to syncronise map reads and writes?

On Wednesday, 23 February 2022 at 03:39:45 UTC yan.z...@gmail.com wrote: > I have also checked the sync.Map and it seems to allow spontaneous reading > but still prohibits spontaneous writing. > I'm not sure what you mean by that. Do you really mean "spontaneous" or "simultaneous"? sync.Map se

[go-nuts] Re: panicOn(err) error handling

I don't think it's a good idea to recommend to beginners that they should write programs that crash. Neither is teaching them a pattern that they will have to discard as soon as they write real programs. Panic doesn't generates user-friendly error messages, it generates stacktraces for a progr

Re: [go-nuts] Is there a way to syncronise map reads and writes?

Unfortunately, that's not how Go maps work. You'll still get races unless you synchronize even "read-only" maps. On Tuesday, February 22, 2022 at 11:59:37 PM UTC-6 ren...@ix.netcom.com wrote: > The top level map locks doesn’t matter - it is write once at init and read > only after. > > On Feb

[go-nuts] panicOn(err) error handling

I find the following function solves all boilerplate issues of error handling in Go for me: func panicOn(err error) { if err != nil { panic(err) } } I use it thus: ... val, err := someFunctionThatCanReturnAnErr() panicOn(err) ... When more refined error handling is needed, it can be replac

Re: [go-nuts] Is there a way to syncronise map reads and writes?

The top level map locks doesn’t matter - it is write once at init and read only after. > On Feb 22, 2022, at 11:51 PM, Jason E. Aten wrote: > > You have not synchronized access to the top level mapLocks map itself. Thus > you will get races. You need to have a mutex that you lock before you

Re: [go-nuts] Is there a way to syncronise map reads and writes?

You have not synchronized access to the top level mapLocks map itself. Thus you will get races. You need to have a mutex that you lock before you access mapLocks; not just the maps that are inside it. I would also recommend being a little object oriented about this design, putting each map ins

Re: [go-nuts] Is there a way to syncronise map reads and writes?

Something else is wrong - because marketMaps is read-only after init… so unless you have some other code - that is not the map causing the panic. My guess is because you are returning the map from ReadMaps (or RWMaps) that you are using THAT map by multiple threads outside the lock (the map is a

[go-nuts] Is there a way to syncronise map reads and writes?

Hi guys! I know this is quite challenging, but it makes sense in io-heavy applications. I need to test the responsiveness of different financial future quotation sources. They return the quotations spontaneously, and my program respond to each one of the CGO call backs from the quotation librar

[go-nuts] Re: Fuzz Testing in Go 1.18

Great job, a nice and gentle introduction. But what's with the 2 minute end screen? On Tuesday, 22 February 2022 at 3:53:07 am UTC+11 a.pl...@gmail.com wrote: > Hi, > > I recently made a video on fuzzing support in Go 1.18. I'd like to hear > your feedback if that's possible - https://youtu.be/