Re: [go-nuts] Enforce immutability through static analysis

I don't think we are talking about the same thing. You can certainly code an immutable object - just don't export any methods that mutate the object, nor export ANY fields. -Original Message- >From: burak serdar >Sent: Nov 21, 2019 11:09 AM >To: Robert Engels >C

Re: [go-nuts] Enforce immutability through static analysis

To clarify - the author of the package enforces immutability. With Go’s design this can be a simple comment on the field. The package shouldn’t be that large where this doesn’t work. > On Nov 21, 2019, at 10:58 AM, Robert Engels wrote: > >  > Correct, but if the receiver method

Re: [go-nuts] Enforce immutability through static analysis

Correct, but if the receiver method is mutating it, then it is not an immutable object. -Original Message- >From: burak serdar >Sent: Nov 21, 2019 10:53 AM >To: Robert Engels >Cc: advanderv...@gmail.com, golang-nuts >Subject: Re: [go-nuts] Enforce immutability

Re: [go-nuts] Enforce immutability through static analysis

They can't unless the instance field is exported. Just hide it via encapsulation with accessors.-Original Message- From: advanderv...@gmail.com Sent: Nov 21, 2019 10:15 AM To: golang-nuts Subject: [go-nuts] Enforce immutability through static analysis Dear Gophers!I was wonder if it

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

Duh, sorry for the spam - I was reading the text without looking at the code. Makes perfect sense. -Original Message- >From: Robert Engels >Sent: Nov 20, 2019 2:31 PM >To: Robert Engels , Ian Lance Taylor , >Orson Cart >Cc: golang-nuts >Subject: Re: [g

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

the other code? -Original Message----- >From: Robert Engels >Sent: Nov 20, 2019 2:25 PM >To: Ian Lance Taylor , Orson Cart > >Cc: golang-nuts >Subject: Re: [go-nuts] Difference with function returning struct and function >returning pointer to struct > > >

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

To be honest, I find this very confusing, especially the statement "Changing a field in that copy won't change anything." because even if I have a copy, I should be able to change the fields, and the changes would be there for the scope, and if I returned the copy, whether by address or copy,

Re: [go-nuts] ultra slow os.Exec

You should include -r to show the relative time stamps. This would be helpful. > On Nov 20, 2019, at 1:58 AM, miha.vrhov...@gmail.com wrote: > >  > The first wait is on read, the 2nd on futex > [pid 20441] read(5, > "\0\0\0@\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) =

Re: [go-nuts] ultra slow os.Exec

-Original Message- >From: Robert Engels >Sent: Nov 19, 2019 10:54 AM >To: Ian Lance Taylor , miha.vrhov...@gmail.com >Cc: golang-nuts >Subject: Re: [go-nuts] ultra slow os.Exec > > >I am guessing - because it is close to 30 secs (which sounds a lo

Re: [go-nuts] ultra slow os.Exec

if I'm reading it correctly >now, I find these results pretty hard to believe. Can anybody else >replicate them? > >Ian > > >> On Tuesday, November 19, 2019 at 4:22:47 PM UTC+1, Robert Engels wrote: >>> >>> >>> I think the point the OP is making is

Re: [go-nuts] ultra slow os.Exec

I think the point the OP is making is that when he runs the command from the Linux command line it completes in 2 sec - so the Wine startup time should not be the issue. -Original Message- >From: Ian Lance Taylor >Sent: Nov 19, 2019 9:15 AM >To: miha.vrhov...@gmail.com >Cc:

Re: [go-nuts] Are M always detached from P when syscall?

I’m pretty sure that if you look deeper not every call ends in “blocking” at least at the os level. Go uses green threads and relies on os level “poll type” support. It has the overhead of its own scheduler but in most cases it is more efficient than the os one. > On Nov 15, 2019, at 9:52 PM,

Re: [go-nuts] pprof cpu profile doesn't write sample to file

gt; 0 0% 100% 450.77ms 98.72% > google.golang.org/grpc/internal/transport.newHTTP2Client.func3 > > > Thanks, > BLN > > > > >> On Friday, 15 November 2019 11:20:59 UTC+5:30, robert engels wrote: >> I think an easier way is to enable t

Re: [go-nuts] pprof cpu profile doesn't write sample to file

I think an easier way is to enable the http based profiling, then just request the profile using the web interface using N seconds - much easier. You can make enabling the http profiling a compile time option. > On Nov 14, 2019, at 10:41 PM, Michael Jones wrote: > > If your program is

Re: [go-nuts] Go gouroutines vs Rust threads

Also, I find the GC model of Go far simpler that the “borrower” model in Rust - but to each their own. I think the “experts” would say use Rust if it is mission critical or needs to meet absolute performance metrics. > On Nov 13, 2019, at 8:13 AM, Robert Engels wrote: > -- You re

Re: [go-nuts] Go gouroutines vs Rust threads

It may be easier - as you can code it in a more procedural fashion, but you can do it in either system - there are many techniques you can use. There are also “green threads” libraries (crates) available for Rust. These may over more control over the internal scheduler as well. > On Nov 13,

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

o add the header really messes up MUAs >that display messages from the same thread together. Does your MUA not >add this header???] > >* Robert Engels [191112 13:00]: >> This is not the issue I am referring to, I am referring to >> https://github.com/golang/go/issues/5

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

gt;concurrently > >[I almost missed this post because you did not reply to the thread.] > >* Robert Engels [191108 11:41]: >> See https://github.com/golang/go/issues/10958 for using atomics in >> tight/busy-wait loops. > >This doesn't have anything to do with atomics.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

The bug I referenced discusses the current problem with the MM specification. You are making assumptions that are not supported by the current MM, but as the bug points out, that is the current behavior. Btw, there is no such thing as "concurrent access". There is a concept of "sharing" and

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

t; On Nov 11, 2019, at 8:02 PM, burak serdar wrote: > > On Sun, Nov 10, 2019 at 7:08 AM Lars Seipel wrote: >> >> On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote: >>> No. Because in the absence on a memory barrier the writes may not be >>> flus

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

What I meant was that if you read farther down in the synchronization section atomics are not discussed and the issue cited is related. > On Nov 10, 2019, at 8:31 AM, Robert Engels wrote: > > Ignore the first part (error!) but the issue applies in terms of atomic. > >>

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

Ignore the first part (error!) but the issue applies in terms of atomic. > On Nov 10, 2019, at 8:08 AM, Lars Seipel wrote: > > On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote: >> No. Because in the absence on a memory barrier the writes may not be flushed >&g

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

09, 2019 at 11:00:04AM -0600, Robert Engels wrote: >> No. Because in the absence on a memory barrier the writes may not be flushed >> meaning you cannot reason about any value ever being changed. atomics >> provide the memory barrier, but the mm still does not specify a “happe

Re: [go-nuts] Map of structs vs Array of structs

WellI ran some tests and that is indeed the case - but it looks like retains a reference to the entire slice (which is expected). Can you point to some documentation on how the GC tracks these interior pointers? > On Nov 9, 2019, at 11:03 AM, Robert Engels wrote: > > Ian, can yo

Re: [go-nuts] Map of structs vs Array of structs

Ian, can you clarify that for me, so the GC tracks interior pointers (to a slice of structs) so that even if there are no references to the outer slice it will not be GCd? That would seem to be very expensive. > On Nov 9, 2019, at 9:36 AM, sirp...@gmail.com wrote: > >  > Thanks for these

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

). > On Nov 9, 2019, at 9:51 AM, Lars Seipel wrote: > > On Fri, Nov 08, 2019 at 06:06:22AM -0600, Robert Engels wrote: >> I think that is a bit unclear - even if they access different elements, if >> they ever access the same element even at different times , you need >> syn

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

-Original Message- >From: burak serdar >Sent: Nov 8, 2019 9:19 AM >To: golang-nuts >Subject: Re: [go-nuts] What is the correct way to access/modify slice elements >concurrently > >On Fri, Nov 8, 2019 at 7:55 AM Marvin Renich wrote: >> >> * burak serdar [191108 08:42]: >> > I

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

Almost always, but it is very difficult as most times you are not really working with a single value (there are implied dependencies). These sort of solutions fall under “lock free” structures/algorithms - and they are fascinating to learn about. > On Nov 8, 2019, at 7:42 AM, burak serdar

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

I think that is a bit unclear - even if they access different elements, if they ever access the same element even at different times , you need synchronization- it’s not only if the access the same element “concurrently”. >> On Nov 8, 2019, at 2:54 AM, Volker Dobler wrote: >  >> On Friday, 8

Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

rom the perspective of someone looking > at the code later and trying to identify performance issues. It's easy to > identify a potentially very costly iteration through a slice if it's more > verbose and always expressed the same way. > >> On Tue, Nov 5, 2019 at 2:44 PM Robert Engels

Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

Is it though?You would have the same problem if you thought the size of mySlice was always small, and it wasn't - range could be quite expensive (or not) - and if that was not valid workable you should be using something other than a slice.You need understanding of the types and cost of operations

Re: [go-nuts] Re: [ANN] A BASIC compiler

Out of curiosity only. > On Oct 26, 2019, at 10:33 AM, Robert Engels wrote: > >  > Why not generate Go? > >>> On Oct 26, 2019, at 9:40 AM, JuciÊ Andrade wrote: >>> >>  >> Feel free to classify the tool anyway you like, Anca. >>

Re: [go-nuts] Re: [ANN] A BASIC compiler

Why not generate Go? > On Oct 26, 2019, at 9:40 AM, JuciÊ Andrade wrote: > >  > Feel free to classify the tool anyway you like, Anca. > > I don't buy the distinction between "compiler" and "transpiler" because it's > the same thing. They read code in some language and generates code in some

Re: [go-nuts] Re: [ANN] A BASIC compiler

Yes. I generates C code from a basic program and you compile the C. > On Oct 26, 2019, at 8:55 AM, Anca Emanuel wrote: > >  > Please explain how it works. > Do you get executables from basic programs ? > > >> On Saturday, October 26, 2019 at 4:40:43 PM UTC+3, JuciÊ Andrade wrote: >> Hi,

Re: [go-nuts] Re: GO Mod (modules) for dummies. Please help.

Don’t be frustrated. The design could be better imo. I am assuming much of the complexity comes from trying to optimize the build across projects that share common modules. I think there are easier ways to accomplish this. Simple mappings to version labels would be easier imo. > On Oct 25,

Re: [go-nuts] pprof not showing call hierarchy for time.now and time.Until

certain cases you end up having to check >> the source of several nodes to see which is the caller. >> >>>> On Sat, 19 Oct 2019, 03:08 Robert Engels, wrote: >>> But also can’t you just find that node in the graph and see the callers? >>> >>>>

Re: [go-nuts] pprof not showing call hierarchy for time.now and time.Until

But also can’t you just find that node in the graph and see the callers? > On Oct 18, 2019, at 8:54 PM, Robert Engels wrote: > >  > Yes. When using the command pprof viewer there is a way to show the hotspots > with the callers. Again I don’t have access to dev at the moment.

Re: [go-nuts] pprof not showing call hierarchy for time.now and time.Until

g what? > So that I could dig down through top and if the function isn't in my code > follow the callstack to find what part of my code > initiated the call. > >> On Fri, Oct 18, 2019 at 8:52 PM Robert Engels wrote: >> I am pretty sure there is a way to filter nodes that

Re: [go-nuts] pprof not showing call hierarchy for time.now and time.Until

I am pretty sure there is a way to filter nodes that are less than X %, and some of that filtering is on by default - so you may want to turn that off (can't say for sure since not at dev machine right now). -Original Message- >From: Ian Lance Taylor >Sent: Oct 18, 2019 2:43 PM

Re: [go-nuts] geocrypt package

Cool stuff! > On Oct 11, 2019, at 4:22 PM, Dan Kortschak wrote: > > Over 10 years ago Gustavo Niemeyer invented the geohash geographic > hashing system https://en.wikipedia.org/wiki/Geohash for clearly and > concisely representing geographic locations at arbitrary precision. > > Now, here is

Re: [go-nuts] Interface method return other interface?

Ugh. Every time I see that I cringe > On Oct 9, 2019, at 7:58 PM, burak serdar wrote: > > On Wed, Oct 9, 2019 at 5:48 PM 'Axel Wagner' via golang-nuts > wrote: >> >> There's loads of precedence in the stdlib: >> >> https://godoc.org/net/http/#FileSystem.Open >>

Re: [go-nuts] Compile Go application with multiple versions of C library

You can create Go plugins too. > On Oct 8, 2019, at 7:57 AM, Vitaly Isaev wrote: > >  > Suggest we're implementing a very specific Go application like data migrator > (for example, the one that transfers data from old database to new database > with different data types). Therefore, this

Re: [go-nuts] Re: An old problem: lack of priority select cases

re, to achievethis goal, we often need two select blocks (sorry, I mis-typed select block as select case in my last comment). One priority-order select block is not only cleaner than two random-order select blocks, but also more efficient.On Fri, Oct 4, 2019 at 1:19 PM T L <tapi...@gmail.co

Re: [go-nuts] Re: An old problem: lack of priority select cases

, etc. make even this simple statement not fully correct).-Original Message- From: T L Sent: Oct 4, 2019 2:44 PM To: golang-nuts Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:You still

Re: [go-nuts] Re: An old problem: lack of priority select cases

You still are not understanding proper concurrent design. Priority select cases do not matter in the case of asynchronous external events. > On Oct 4, 2019, at 1:46 PM, T L wrote: > >  > I just found an example in the "context" package docs: > > // // Stream generates values with

Re: [go-nuts] Channels may not be the best solution in Go

A point to consider though, is that often sequential code is used and concurrency is achieved by running multiple processes. This is pretty much the design of the cloud. A top-level coordinator partitions the work-load, and sequential programs process it, and the top-level assembles the results -

Re: [go-nuts] Golang library for - ORM & Schema Migration

ORM is object relational mapping. Go is only pseudo object oriented. I will say again that complex object graphs and persistence is very hard without an ORM or a LOT of custom code. Since Go does not have runtime compilation a true (or easy anyway) ORM in Go requires code generation. > On

Re: [go-nuts] Golang library for - ORM & Schema Migration

It was supposed to be “without an ORM”... > On Sep 27, 2019, at 1:27 PM, Robert Engels wrote: > > And I’ll reiterate that you’re (and the article) is missing the point. > > Using a simple case of customers and orders. With an ORM when you want to > show all orders

Re: [go-nuts] Golang library for - ORM & Schema Migration

And I’ll reiterate that you’re (and the article) is missing the point. Using a simple case of customers and orders. With an ORM when you want to show all orders for all customers with the customer details, you need to join the customer with the order in every row. This is a huge waste of

Re: [go-nuts] Golang library for - ORM & Schema Migration

The piece you are missing about ORM is the automatic change detection and caching when using complex object graphs. This is not trivial by any means when using raw SQL. It’s not easy using an orm either sometimes - depends on the orm. > On Sep 27, 2019, at 6:13 AM, Dimas Prawira > wrote: >

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

As someone that has worked with a lot of similar libraries in the HFT space - things like UnsafeString or FastString in Java I would caution against doing this in Go - especially as proposed here. Taking an immutable object like string and making it mutable by accident is a recipe for disaster.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

Heh, didn’t know that and independently came up with it in 30 secs - that has to be worth something ? (Although mine uses sampling of all event sources) > On Sep 8, 2019, at 4:19 PM, burak serdar wrote: > >> On Sun, Sep 8, 2019 at 3:16 PM Robert Engels wrote: >> >>

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

It’s hard to respond. I have done a lot of concurrent programming and haven’t heard the term “vector clock” so I am not sure what you are referring to. You can write a logical “clock cycle” by sampling both and choosing the higher priority event - but overall performance is going to suffer

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

You need to code it knowing that either can occur in any order. > On Sep 8, 2019, at 10:14 AM, changkun wrote: > > Hi, golang nuts, > > Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG > > In the code snippet, a ticker is activating and another that that is closing, > it

Re: [go-nuts] An old problem: lack of priority select cases

was generating log messages).For the version I posted, every write that completes will be handled by a consumer.-Original Message- From: Leo Lara Sent: Sep 4, 2019 8:24 AM To: Robert Engels Cc: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases By encapsulation

Re: [go-nuts] An old problem: lack of priority select cases

lready an optimisation to my code, I think using a >>> RW lock, if I put the "Add(1)" in a read lock and the wait in a Write lock >>> it might work better. The race condition that my lock prevents is only >>> related when an "Add" and a "Wait&qu

Re: [go-nuts] An old problem: lack of priority select cases

hat simple lock would work with several >>> goroutines, but I think there would be more contention with this lock. >>> >>> Anyway, I think I have already an optimisation to my code, I think using a >>> RW lock, if I put the "Add(1)" in a read loc

Re: [go-nuts] playground - time.Sleep causes deadlock

to be reported as closed all other writes prior must be visible. > On Sep 2, 2019, at 6:52 PM, Robert Engels wrote: > > As far as I know you are attributing properties to the memory model that > don’t yet exist - they’re working on it. Even the “happens before” in > relation to atomics is

Re: [go-nuts] playground - time.Sleep causes deadlock

writes, go ahead. This is definitely safer. But I think when the full memory model spec arrives it won’t be necessary. > On Sep 2, 2019, at 6:02 PM, roger peppe wrote: > > > >> On Mon, 2 Sep 2019, 21:32 robert engels, wrote: >> (you’re comments were quoted, but I think

Re: [go-nuts] playground - time.Sleep causes deadlock

(you’re comments were quoted, but I think I am replying correctly). The memory barriers provided by the Write Lock, and release will force the flush to memory of all mutations before the flush (the closed mutation) - meaning the atomic read will read the correct value. There is a chance that a

Re: [go-nuts] An old problem: lack of priority select cases

to be atomic but it’s not needed. > On Sep 1, 2019, at 12:55 PM, T L wrote: > > You can simply validate it by run: go run -race main.go > for you program: https://play.golang.org/p/JRSEPU3Uf17 > > >> On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote: >&

Re: [go-nuts] An old problem: lack of priority select cases

September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >> That is incorrect. The atomic operations must exhibit the same happens >> before relationships as the mutex. If the mutex flushes the related cache >> lines the atomic load will pick it up. >> &g

Re: [go-nuts] playground - time.Sleep causes deadlock

Btw, the removing of the GOMAXPROCS causes things to execute serially- which is fine according to the spec - but it does make demonstrating certain concurrency structs/problems pretty difficult. > On Sep 1, 2019, at 7:05 AM, robert engels wrote: > > The point about ‘mu’ is valid. Ra

Re: [go-nuts] playground - time.Sleep causes deadlock

The point about ‘mu’ is valid. Rather than ‘closed’, it should really be an ‘error’ given the situation - as it is more applicable to the operation failures (as a black box IO component). > On Sep 1, 2019, at 6:46 AM, Robert Engels wrote: > > As I pointed out in another reply, I

Re: [go-nuts] playground - time.Sleep causes deadlock

ves the unnecessary (and probably wrong) atomic load > - it allows direct access to the channel for reading (and select etc) - no > need to hide it behind the Read method. > - mutex fields are very often named "mu" > > cheers, > rog. > >> On Sat, 31 Aug 2

Re: [go-nuts] An old problem: lack of priority select cases

t 9:49:56 PM UTC-4, Robert Engels wrote: >> Yes, that is why the original code did not use a lock on the read but the >> read of the flag was wrong. The version I posted in the other thread works >> fine locally. time.Sleep() has problems in the playground > > You mean this

Re: [go-nuts] An old problem: lack of priority select cases

y, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote: >> If you comment out the read method then all threads will block. That is the >> the behavior of an unbuffered channel - a writer blocks until a reader is >> ready. Which is why you always need a valid reader runni

Re: [go-nuts] playground - time.Sleep causes deadlock

t; On Sat, Aug 31, 2019 at 4:13 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: >> >> The code at https://play.golang.org/p/9ZdPVvwyaYK >> <https://play.golang.org/p/9ZdPVvwyaYK> >> >> should not deadlock. But it reports: >

[go-nuts] playground - time.Sleep causes deadlock

The code at https://play.golang.org/p/9ZdPVvwyaYK should not deadlock. But it reports: fatal error: all goroutines are asleep - deadlock! But if you look at the stack traces, you see multiple routines (sampled) like: goroutine 1 [sleep]:

Re: [go-nuts] An old problem: lack of priority select cases

is valid. > On Aug 31, 2019, at 2:40 AM, T L wrote: > > > >> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote: >> You changed the Read() method incorrectly - it should be using the Read >> lock, not the Write lock. >> >> Still, a

Re: [go-nuts] An old problem: lack of priority select cases

: Aug 30, 2019 12:05 PM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:Makes no difference in the code I posted as long as they all use the same MultiWriterChannel. In fact, others can

Re: [go-nuts] An old problem: lack of priority select cases

] An old problem: lack of priority select cases On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:I don't think so. Why do you think that is the case? The RWLock is "fair" in the sense that once the 'closer' attempts to get the lock, it is guaranteed to get it (a

Re: [go-nuts] An old problem: lack of priority select cases

at 8:59:10 PM UTC-4, Robert Engels wrote:Oops. You are right. The original used two different methods Closed() and Read() and when I refactored I forgot to add the Read lock to the Read(). That's why you always have code reviews...-Original Message- From: T L Sent: Aug 29, 2019 6:25 PM To:

Re: [go-nuts] An old problem: lack of priority select cases

] An old problem: lack of priority select cases On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlfDoesn't the Read method need to be guarded by the reader lock? It won’t run correctly in the playground because

Re: [go-nuts] An old problem: lack of priority select cases

ted > when an "Add" and a "Wait" run concurrently, several "Add" can run > concurrently. > >> On Thursday, August 29, 2019 at 4:05:06 AM UTC+2, robert engels wrote: >> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf >> >> I

Re: [go-nuts] An old problem: lack of priority select cases

> For example, if you want to write a library where the user just reads from a > channel, this is an approach I found where the user of the lirbary deos nto > have to do anything special. Of course, there might be another solution, but > if you need to modify the reader we are talking

Re: [go-nuts] An old problem: lack of priority select cases

I will write and post this evening. -Original Message- From: T L Sent: Aug 28, 2019 1:11 PM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Wednesday, August 28, 2019 at 1:49:51 PM UTC-4, Robert Engels wrote:As I said in another email, using

Re: [go-nuts] An old problem: lack of priority select cases

To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote:And what I was trying to say is that request is inherently racy.You can already do priority selects. see https://play.golang.org/p/58FfsKIivSr

Re: [go-nuts] Re: An old problem: lack of priority select cases

A better solution is to wrap the writes using a RWLock, grab the read lock for writing, and the Write lock for closing. Pretty simple.Just encapsulate it all in a MultiWriterChannel struct - generics would help here :)-Original Message- From: Leo Lara Sent: Aug 28, 2019 11:24 AM To:

Re: [go-nuts] Re: An old problem: lack of priority select cases

Reading the article, why not just wrap the write function in one that uses panic/recover, since the write is expected to panic if the channel is closed.-Original Message- From: Leo Lara Sent: Aug 28, 2019 11:24 AM To: golang-nuts Subject: [go-nuts] Re: An old problem: lack of priority

Re: [go-nuts] An old problem: lack of priority select cases

- From: T L Sent: Aug 28, 2019 11:43 AM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote:That's inherently racy - since between when the runtime determines the channel is OK for writing

Re: [go-nuts] An old problem: lack of priority select cases

That's inherently racy - since between when the runtime determines the channel is OK for writing, another routine can close the channel before the write is attempted - so "priorities" won't help.-Original Message- From: T L Sent: Aug 28, 2019 11:06 AM To: golang-nuts Subject: [go-nuts]

Re: [go-nuts] Goroutine scheduled 10 seconds too late

I suggest using pstack to capture the stacks of all threads of you can. Because it is external ut is not subject to the stopping bias of the internal go facilities. > On Aug 27, 2019, at 9:05 AM, Ian Lance Taylor wrote: > >> On Mon, Aug 26, 2019 at 2:12 PM Michael Andersen >> wrote: >> >>

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

e difference between chan and mutex implementation, here I am comparing > mutex with difference number of goroutines. > Basically what you suspected doesn't match what was observed from statistics. > >> On Tuesday, August 27, 2019 at 12:34:25 AM UTC+2, Robert Engels wrote: >>

Re: [go-nuts] Multiple interface addresses and UDPConn.WriteToUDP

not be required - this is the underlying principle of internet routing. > On Aug 26, 2019, at 7:38 PM, Robert Engels wrote: > > If the network is set up properly the kernel should chose the correct network > interface based on the destination IP address. > > The only time

Fwd: [go-nuts] Multiple interface addresses and UDPConn.WriteToUDP

Begin forwarded message: > From: Robert Engels > Date: August 26, 2019 at 7:38:20 PM CDT > To: Tanner Ryan > Subject: Re: [go-nuts] Multiple interface addresses and UDPConn.WriteToUDP > > If the network is set up properly the kernel should chose the correct network

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

, Robert Engels wrote:You might want to try 'perf mem' to report the access delays - it may be contention on the memory controller as well.Thinking about it again, I wouldn't expect a large jump if things were fair - for example, if at 100 they all fit in the cache, at 110, some are still

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

)2400697103572176416860.97531751943200798160789541697840.9364451004336013879724731484156780.9033996208360018245410622721663550.8701934506400020537794013935865010.8391795437480018856222754618728990.8032486268On Monday, August 26, 2019 at 9:26:05 PM UTC+2, Robert Engels wrote:You can run the process under 'perf' and monitor the cpu cache hit/miss ratio.-Original Message

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

.On Monday, August 26, 2019 at 8:08:27 PM UTC+2, Robert Engels wrote:Which is what I would expect - once the number of routines exhaust the cache, it will take the next level (or never since its main memory) to see an massive increase in time. 4800 is 30% slower than 3600 - so it is increasin

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

August 26, 2019 at 8:08:27 PM UTC+2, Robert Engels wrote:Which is what I would expect - once the number of routines exhaust the cache, it will take the next level (or never since its main memory) to see an massive increase in time. 4800 is 30% slower than 3600 - so it is increasing linearly with

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

Which is what I would expect - once the number of routines exhaust the cache, it will take the next level (or never since its main memory) to see an massive increase in time. 4800 is 30% slower than 3600 - so it is increasing linearly with the number of Go routines.-Original Message- From:

Re: [go-nuts] Re: I know you cannot kill a goroutine, but ...

You have to be careful with this approach and high volume (longer latency) tcp. Often there can be TCP "stalls" and if you have a messaging type protocol, you need to make sure you can handle partial reads and re-combine, because the deadline may fire during the read (typically a problem with text

Re: [go-nuts] Odd runtime errors

Disheartening, but not unfamiliar - very reminiscent of Java days. I would highly encourage removing any dependencies that use CGO or Unsafe - and move to pure Go. This seemed to be the only way to tame these sort of errors in the wild in Java land. Also, have you done stress tests using the

Re: [go-nuts] Goroutine scheduled 10 seconds too late

If you write an long running non pre-emptable all go routines are effected. > On Aug 23, 2019, at 4:03 PM, Michael Andersen wrote: > > > >> On Fri, Aug 23, 2019 at 1:23 PM Ronny Bangsund >> wrote: >>> On Friday, August 23, 2019 at 5:58:44 PM UTC+2, Michael Andersen wrote: >>> It can take a

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

that shows the number of iterations per routine: https://play.golang.org/p/LkAvB39X3_Z > On Aug 21, 2019, at 6:31 PM, Robert Engels wrote: > > I don't think you've posted code for the atomic version... > > Each Go routine has its own stack. So when you cycle through many Go

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

is relevant to https://github.com/golang/go/issues/33747The issue talked about small contention on large Ps, but a full scale of my benchmark is shown as follows:On Tuesday, August 20, 2019 at 6:10:32 PM UTC+2, Robert Engels wrote:I am assuming that there is an internal Go structure/process that whe

Re: [go-nuts] A problem about runtime.SetFinalizer

I understand the first part, but the second? Why is the finalizer function passed a reference to the object being finalized then? -Original Message- >From: Ian Lance Taylor >Sent: Aug 21, 2019 12:06 PM >To: Robert Engels >Cc: zct , golang-nuts > >Subject: Re: [

Re: [go-nuts] A problem about runtime.SetFinalizer

Seems like GoLint should emit an 'unused parameter' in this case.-Original Message- From: zct Sent: Aug 21, 2019 10:50 AM To: golang-nuts Subject: Re: [go-nuts] A problem about runtime.SetFinalizer I got it.Thank you for your help在 2019年8月21日星期三 UTC+8下午11:00:26，Ian Lance Taylor写道：On

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

ular debug settings you referring to?It is reasonable that sync.Mutex rely on runtime scheduler but channels do not. However, it is unclear why a significant performance drop appears. Is it possible to determine when the performance will appear?Best,ChangkunOn Monday, August 19, 2019 at 10:27:19 PM UTC

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

> > On Monday, August 19, 2019 at 10:27:19 PM UTC+2, Robert Engels wrote: > I think you'll find the reason that the Mutex uses the Go scheduler. The chan > is controlled by a 'mutex' which eventually defers to the OS futex - and the > OS futex is probably more efficient at sched

<    5   6   7   8   9   10   11   12   13   14   >