Re: [go-nuts] Go without garbage collector

mistakes (made by fresh-from college developers?) is > all over the place. Honestly, I think that they pessimized the C++ code until > they reached the desired outcome. > > If you want a somewhat more realistic range of benchmarks, look at Debian's > Benchmark game: > https://ben

Re: [go-nuts] Go without garbage collector

Also, I installed gnu gcc 9.2 and used it rather than the OSX clang, and optimized C++ (-O2) time was 17.9 secs. > On Feb 12, 2020, at 11:59 PM, robert engels wrote: > > Here is some pretty indisputable evidence on the advancements of GC/JVM vs > C++. > > See this p

Re: [go-nuts] Go without garbage collector

static compilation/optimization not so much… Stressing again - ZERO CODE CHANGES ! Enjoy ! > On Feb 12, 2020, at 10:17 PM, Robert Engels wrote: > > G1GC only went into production with Java 7 in 2011. > > I don’t think you understand how Zing works. Furthermore, malloc based &g

Re: [go-nuts] Go without garbage collector

GC > for a shared-memory system seems to be a fool's errand. By leaving out > compaction, the benefits of GC become even less appealing. > >> On Wednesday, February 12, 2020 at 2:57:04 PM UTC-8, Robert Engels wrote: >> GCs have radically improved since then - at least in practic

Re: [go-nuts] Go without garbage collector

they are worse now in massively-parallel environment than on single-core CPUs of yore.On Tuesday, February 11, 2020 at 8:54:29 PM UTC-8, robert engels wrote:Here is a paper from 2005 https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf that proves otherwise.GC techniques have radically improved since

Re: [go-nuts] Go without garbage collector

s not to be true in the wild although I am sure theoretical cases can be envisioned.On Wed, 12 Feb 2020, 16:06 Kevin Chadwick, <m8il1i...@gmail.com> wrote:On 2020-02-12 14:02, Robert Engels wrote: > Most of that is because their codebase predates Java. There are more modern dbs > like Cassandra

Re: [go-nuts] Go without garbage collector

) or when predictable performance is very important (realtime > systems). > > -- Marcin > >> On Tue, Feb 11, 2020 at 9:00 PM robert engels wrote: >> I found a more recent academic paper that proves my conclusions: >> >> https://www.researchgate.net/publication

Re: [go-nuts] Go without garbage collector

uot; often and it seems not to be true in the wild although I am sure theoretical cases can be envisioned.On Wed, 12 Feb 2020, 16:06 Kevin Chadwick, <m8il1i...@gmail.com> wrote:On 2020-02-12 14:02, Robert Engels wrote: > Most of that is because their codebase predates Java. There are more modern d

Re: [go-nuts] Go without garbage collector

mething that a GC can do by itself. What > it brings is convenience and frankly it's "good enough" > for most cases. We shouldn't pretend that GC is be all end all to both > developer and runtime performance. > >> On Wed, Feb 12, 2020 at 2:10 PM Robert Engels wrote: >&g

Re: [go-nuts] Go without garbage collector

ote: > >  >> On Wednesday, 12 February 2020 05:00:41 UTC, robert engels wrote: >> I found a more recent academic paper that proves my conclusions: >> >> https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection >>

Re: [go-nuts] Go without garbage collector

ou can search and find many more, but the principles stated in the above are going to apply regardless. > On Feb 11, 2020, at 10:53 PM, robert engels wrote: > > Here is a paper from 2005 > https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf > <https://people.cs.umass.edu/~e

Re: [go-nuts] Go without garbage collector

ory management seems > to be outperforming GC in majority of cases. > > On Tuesday, February 11, 2020 at 5:59:26 PM UTC-8, robert engels wrote: > It’s been PROVEN that GC outperforms all manual memory management except in > EXTREMELY isolated cases (very non-traditional all

Re: [go-nuts] Go without garbage collector

It’s been PROVEN that GC outperforms all manual memory management except in EXTREMELY isolated cases (very non-traditional allocation or deallocation patterns). It’s all about constraints and tolerances. You design a “system” that takes both into account - if not, you’re not engineering,

Re: [go-nuts] Why Discord is switching from Go to Rust

If you use any dynamic memory strict latency is very very difficult in any language/platform. I’m not really sure how a platform like Discord has strict latency requirements - it’s not as if the ‘read badge’ not updating is going to crash the plane. As an example a lot of auto systems use

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

I would caution that reduced performance with ondemand might be a good thing. If the job is doing lots of IO this means the process has little/less overhead so less drain on the cpu meaning it takes a while to spin back up. If both governors show the serious degradation I would be far more

Re: [go-nuts] Why Discord is switching from Go to Rust

I think if you look into Zing or Shenandoah you’ll find a different experience. Literally zero tuning required. > On Feb 7, 2020, at 3:29 PM, Marcin Romaszewicz wrote: > >  > > >> On Fri, Feb 7, 2020 at 11:43 AM Robert Engels wrote: >> I didn’t look into the

Re: [go-nuts] Why Discord is switching from Go to Rust

I didn’t look into the project but reading between the lines here I am betting that Java would perform as well as Rust in this case. This is an example of where not having generational GC hurts badly - since it appears that most of their heap would be very long lived objects. > On Feb 7,

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

And I’ll repeat, you probably need a pool to limit the number of concurrent processes/connections. If you had that you would probably of detected the problem sooner. > On Feb 5, 2020, at 6:32 PM, Robert Engels wrote: > >  > I am not familiar with YouTube-dl but if you can pa

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

tput, are you saying make a go routine to >> write to the headers? If you have an example I would appreciate it >> >>> On Wednesday, February 5, 2020 at 8:47:05 AM UTC-7, Robert Engels wrote: >>> I think your problem may be >>> >>> "D

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

elieve that may be problem, that they hang. > > And when you say append the output, are you saying make a go routine to write > to the headers? If you have an example I would appreciate it > >> On Wednesday, February 5, 2020 at 8:47:05 AM UTC-7, Robert Engels wrote: >> I think

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

s malloced but never freed, >or in Go code with memory that something keeps a permanent reference >to. > >Ian > > >> On Tuesday, February 4, 2020 at 2:00:55 PM UTC-7, Robert Engels wrote: >>> >>> Are you certain you are not just starting too many processes? Ie use a &g

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

Are you certain you are not just starting too many processes? Ie use a “worker pool” so you have at most N conversions happening at the same time. > On Feb 4, 2020, at 2:34 PM, Robert Engels wrote: > >  > I will take a more in-depth look this evening. > >>> On

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

I will take a more in-depth look this evening. > On Feb 4, 2020, at 2:19 PM, jnaderl...@gmail.com wrote: > >  > I also thought the Wait() took care of closing the file descriptors? Are you > saying I should add a pipe3.Close()? Or a youtube.Close()? > -- > You received this message because

Re: [go-nuts] runtime/cgo: pthread_create failed: Resource temporarily unavailable

When you reassign the file descriptors you need to close the old ones - this does not happen automatically. You also need to close the ffmpeg fds. By not closing the descriptors the pipe structures are remaining in the kernel. That’s my first guess anyway. > On Feb 4, 2020, at 7:21 AM,

Re: [go-nuts] types of slice indices and range operators

*generics :) > On Feb 2, 2020, at 9:27 PM, Robert Engels wrote: > >  > I think the major difference is that by using EventID as a constrained type, > you are then attempting to constrain index values - for which there are no > constraints other than slice length. >

Re: [go-nuts] types of slice indices and range operators

lly guarantees that the values are suitable for slice indexing. I'm > simply trying to alleviate the need for excess, error-prone casting when > doing so. > > Regards, > Steve > > >> On Sun, Feb 2, 2020 at 6:37 PM Robert Engels wrote: >> One last point, if

Re: [go-nuts] types of slice indices and range operators

One last point, if you are interested in type safety, why not create simple structs like EventList to encapsulate the indexing, etc. Trivial and can be done today. > On Feb 2, 2020, at 8:28 PM, Robert Engels wrote: > >  > Also, what you are asking for I believe is covered

Re: [go-nuts] types of slice indices and range operators

ndex. > > Regards, > Steve > > >> On Sun, Feb 2, 2020 at 5:56 PM Robert Engels wrote: >> You are using range incorrectly - you are using the index not the value. >> >> See https://tour.golang.org/moretypes/16 >> >>>> On Feb 2, 2020, at 7:39 P

Re: [go-nuts] types of slice indices and range operators

ple, take a look through the standard library code: you'll find a great > many instances of range loops using only the index. > > Regards, > Steve > > >> On Sun, Feb 2, 2020 at 5:56 PM Robert Engels wrote: >> You are using range incorrectly - you are using the in

Re: [go-nuts] types of slice indices and range operators

You are using range incorrectly - you are using the index not the value. See https://tour.golang.org/moretypes/16 > On Feb 2, 2020, at 7:39 PM, Steve Roth wrote: > >  > Greetings, > > I'm considering submitting a proposal for a language change, and would like > some informal feedback on

Re: [go-nuts] Re: keep just 2 decimal places in a float64

> >> On Sunday, January 26, 2020 at 8:46:16 AM UTC-8, Robert Engels wrote: >> Which is exactly what github.com/robaho/fixed and many others do! >> >>>> On Jan 26, 2020, at 10:34 AM, Michael Jones wrote: >>>> >>>  >>> ...thus the v

Re: [go-nuts] Go Tool to convert svg to png/jpg

re in addition to what you really seem to >> want, which is a fully Go SVG -> PNG renderer.) >> >> Good luck in your project, >> michael >> >> On Fri, Jan 31, 2020 at 6:03 PM robert engels wrote: >> There is no cross-platform graphics library incl

Re: [go-nuts] Go Tool to convert svg to png/jpg

There is no cross-platform graphics library included in Go. Most likely you’ll need a C binding to Qt or similar to perform the rasterization. You might be able to put one together using something like https://github.com/hajimehoshi/ebiten > On Jan 31, 2020, at 7:31 PM,

Re: [go-nuts] Is it considered to separate runtime and cmd/compile irrelevant standard libraries out from the core language repo and hosted in a different module, eg. std?

is my trivial program such a large binary? <https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary> I do not think something like this exists. > On Jan 27, 2020, at 3:33 PM, Ian Lance Taylor wrote: > > On Mon, Jan 27, 2020 at 1:27 PM Robert Engels <mailto:ren

Re: [go-nuts] Re: Is it considered to separate runtime and cmd/compile irrelevant standard libraries out from the core language repo and hosted in a different module, eg. std?

Doesn’t this piggyback on making the runtime a shared library so it can be updated without application recompile? > On Jan 27, 2020, at 2:24 PM, Ian Lance Taylor wrote: > > On Mon, Jan 27, 2020 at 7:02 AM 'Axel Wagner' via golang-nuts > wrote: >> >> The original message mentions size. The

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

easy prototyping != scaling Pick one. > On Jan 27, 2020, at 1:42 PM, Liam Breck wrote: > >  > Go mindshare suffers if it's seen as worse for prototyping, and necessary > only for scale. Especially as there are more efficient (albeit more complex) > ways to achieve scale. > >> On Mon,

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Developer: not sure this is going to work... use Python for POC SVP: Looks great! Ship it! Developer: but wait... > On Jan 27, 2020, at 11:05 AM, Michael Jones wrote: > >  > Python, to its credit, has the nice inclusive property of extensible > interpreters of being friendly to "hang things"

Re: [go-nuts] Experience report on a large Python-to-Go translation

against anything written in Python… :) > On Jan 26, 2020, at 10:09 PM, Eric Raymond wrote: > > > > On Sunday, January 26, 2020 at 9:06:47 PM UTC-5, Robert Engels wrote: > I think trying to write Python in Go is problematic. > > Of course it is. If I were starting a G

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

I think trying to write Python in Go is problematic. You say you intentional did and didn’t worry about “improving” the code. Using interfaces and Go design patterns is not improving - it’s writing proper Go imo. > On Jan 26, 2020, at 6:14 PM, pboampo...@gmail.com wrote: > >  > > ===

Re: [go-nuts] Re: keep just 2 decimal places in a float64

ng > bad about floating point despite the reputation, it's just not the number > system from algebra; nor is binary floating point the same as decimal > floating point. The problems all start with false presumptions. > >> On Sun, Jan 26, 2020 at 8:20 AM Robert Eng

Re: [go-nuts] Re: keep just 2 decimal places in a float64

Just an FYI, often that is not correct. Many financial systems require fractional pennies due to the volume of transactions. Think about taxing stock exchanges the pennies add up quickly at any tax rate, so they use fractional pennies to reduce the size of the error bucket. > On Jan 26,

Re: [go-nuts] keep just 2 decimal places in a float64

You can use github.com/robaho/fixed :) > On Jan 25, 2020, at 11:40 PM, Jamil Djadala wrote: > > On Sat, 25 Jan 2020 19:14:15 -0800 (PST) > "Jason E. Aten" wrote: > >> >> https://play.golang.org/p/87bDubJxjHO >> >> I'd like to truncate a float64 to just 2 decimal places (in base 10), >> but

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

Very in-depth and interesting. Although I agree with most of the points, I think a better use of interfaces would address some of your concerns, and have more maintainable code. Whenever I see a type switch it screams to me “use an interface and restructure. “ >> On Jan 25, 2020, at 4:43

Re: [go-nuts] Is there some kind of a MaxHeapAlarm implementation?

? > >On 2020-01-23 14:18, robert engels wrote: >> There is nothing “special” about it - generally the Go process calls >> “malloc()” and fails with OOM (unable to expand the process memory size), >> but the OS can kill processes in a low system memory condition without them

Re: [go-nuts] Is there some kind of a MaxHeapAlarm implementation?

pointing out, rather than failing the GC will free “soft refs” to make room. > On Jan 23, 2020, at 6:13 AM, Kevin Chadwick wrote: > > On 2020-01-20 18:57, Robert Engels wrote: >> This is solved pretty easily in Java using soft references and a hard memory >> cap. >>

Re: [go-nuts] Is there some kind of a MaxHeapAlarm implementation?

, but maybe they have an Unsafe/CGO way. I haven’t really researched the WeakRef packages for Go. > On Jan 20, 2020, at 4:58 PM, Eric S. Raymond wrote: > > Robert Engels : >> This is solved pretty easily in Java using soft references and a hard memory >> cap. > > That'd

Re: [go-nuts] Is there some kind of a MaxHeapAlarm implementation?

This is solved pretty easily in Java using soft references and a hard memory cap. Similar techniques may work here. > On Jan 20, 2020, at 11:22 AM, Christian Mauduit wrote: > > Hi, > > That is a generic question and I think that if you want to keep an approach > with a "global indicator

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Porsche’s sales are a tiny fraction of auto sales, but most in the industry consider it to be the best platform - and only wish they could emulate / afford to be in that conversation. > On Jan 16, 2020, at 2:10 PM, Liam wrote: > >  > Open source is a rapidly growing movement across

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Well said. > On Jan 16, 2020, at 9:58 AM, Michael Jones wrote: > >  > How global mindshare develops is something that I know quite a bit about > through leadership and engineering experience in multiple billion user > projects. > > One key lesson for me was that you reach a point where

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Please look deeper into how these "trends" are calculated.For example, if everyone that uses product Y can't figure out how feature X works, and they search for it. Product Y will be showing growth...-Original Message- From: Liam Sent: Jan 15, 2020 4:18 PM To: golang-nuts Subject:

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

: > > func identity(i int) int { > return i > } > > func modify(i *int) error { > *i = 1 > return nil > } > > func f() (int, error) { > i := 0 > return identity(i), modify() // returns 0, nil > } > > >&g

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

or) { >x := { > Foo: f, >} >return x, x.intialize() > } > > You can say that you shouldn't do something like this, but it's IMO > reasonable code to write and it expects different behavior. > > However, as per my previous e-mail, I would stil

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

I think the way to look at it is “what would be the behavior of if you were inline creating and initializing a struct containing both values” - clearly this behavior is not what you would want or expect. > On Jan 15, 2020, at 1:25 PM, Paul Jolly wrote: > >  >> >> "when evaluating the

Re: [go-nuts] [ANN] github.com/perillo/workon command

You might find visual studio code appealing for your Go development. > On Jan 15, 2020, at 11:58 AM, Manlio Perillo wrote: > >  > Hi. > > I have several relatively small personal projects. Every time I want to work > on them I need to launch a new terminal emulator and then open all the

[go-nuts] performance improvements

Shout out to the Go team on a job well done. I took the time to re-run some benchmarks, here are the results (both 1.9.7 and 1.13.5 re-run on same hardware & OS). >From fixed iMac:tmp robertengels$ benchcmp bench_1_9_7.txt bench_1_13_15.txt benchmark

Re: [go-nuts] How to reduce the fluctuation of micro benchmark results

Take a look at https://github.com/golang/go/issues/24735 You probably want to increase benchtime to a larger value, even 10x. > On Jan 7, 2020, at 8:44 PM, Xiangdong JI wrote: > > BTW. 'drop cache' is made, while setting cpu governor is not

Re: [go-nuts] Re: distributed runtime

I think you want to use “nats streaming”. It does throttling via ACKs. > On Jan 6, 2020, at 7:35 AM, Jason E. Aten wrote: > >  >>> On Mon, Jan 6, 2020 at 6:24 AM Robert Engels wrote: >>> I’m pretty sure Nats.io has all of the same delivery guarantees as

Re: [go-nuts] Re: distributed runtime

I’m pretty sure Nats.io has all of the same delivery guarantees as rabbitmq. What design is not accommodated by mats? > On Jan 6, 2020, at 4:56 AM, ffm2...@web.de wrote: > >  > >> >> However, if you want to apply supervision for distributed Go channels you >> have to change from channels to

Re: [go-nuts] A question !

Well, don’t benchmark it, bookmark it :) > On Jan 4, 2020, at 5:51 PM, robert engels wrote: > > Please everyone just benchmark this page > https://www.techempower.com/benchmarks/ > <https://www.techempower.com/benchmarks/> > > Rant ON... Python is not suitable

Re: [go-nuts] A question !

Please everyone just benchmark this page https://www.techempower.com/benchmarks/ Rant ON... Python is not suitable for any high volume server application. It is designed for simple scripting. Rant OFF. > On Jan 4, 2020, at 5:41 PM, Justin Israel

Re: [go-nuts] Locking goroutine to "main" thread

Also, even simpler - just remove the time.Atfter case() and use a default: - but the problem is you will spin a single thread at 100% cpu - you really need to use a blocking sdl.WaitEvent() > On Jan 3, 2020, at 6:04 PM, robert engels wrote: > > You only need a single thread locked

Re: [go-nuts] Locking goroutine to "main" thread

spawn this from the init() but I think that might make things harder. You can sync the calls so only a single routine/thread will ever be created. > On Jan 3, 2020, at 6:04 PM, robert engels wrote: > > You only need a single thread locked to the UI thread. > > Use one Go

Re: [go-nuts] Locking goroutine to "main" thread

g two goroutines to the UI thread, I could split this > loop into two separate loops and remove the time.After, I *think*. > > On Friday, January 3, 2020 at 2:59:42 PM UTC-8, robert engels wrote: > You can definitely run the event loop for a process on a thread other than > main. The main thr

Re: [go-nuts] Locking goroutine to "main" thread

in the thread that initialized the video > subsystem." > > > On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote: > Even if you could I don’t think you would want to do it this way. > > Have a go routine sleep on a channel. Post to the channel from the na

Re: [go-nuts] Locking goroutine to "main" thread

Even if you could I don’t think you would want to do it this way. Have a go routine sleep on a channel. Post to the channel from the native code. Let your command loop run on any thread and synchronize via a channel the calls to/from native. The os event loop doesn’t need to run on main -

Re: [go-nuts] Re: net.conn TCP connection

fast, so using a messaging library may help. > On Dec 31, 2019, at 10:37 AM, Robert Engels wrote: > >  > All of the source is there... but in general it is a bit more complex under > the covers than most - as it uses select/poll to know when a socket is ready > for

Re: [go-nuts] Re: net.conn TCP connection

All of the source is there... but in general it is a bit more complex under the covers than most - as it uses select/poll to know when a socket is ready for IO then schedules the routine in the Read() to perform the IO. So Go has a bit of its own kernel code than you would see in typical

Re: [go-nuts] Re: net.conn TCP connection

One other note, if you have a request / response type protocol with fairly defined lengths, you don’t need a buffer larger than the largest message if you don’t allow concurrent requests from the same client. > On Dec 31, 2019, at 9:35 AM, Robert Engels wrote: > >  > The impor

Re: [go-nuts] Re: net.conn TCP connection

The important factors: 1) the larger the buffer the fewer system calls that need to be made 2) the larger the buffer the more memory use which can be significant with many simultaneous connections You need to remember that with correct socket options the kernel is already buffering, and adding

Re: [go-nuts] Re: net.conn TCP connection

Oh, and I don’t think SCTP is natively supported on Windows yet. So your interoperability May vary... > On Dec 30, 2019, at 4:17 PM, Robert Engels wrote: > >  > Im pretty sure I’m correct. It is a socket type not an option on TCP, which > equates to a different proto

Re: [go-nuts] Re: net.conn TCP connection

t;> On Mon, Dec 30, 2019 at 12:23 PM Robert Engels wrote: >> That option requires proprietary protocols not standard tcp/udp. >> >>>> On Dec 30, 2019, at 12:04 PM, Bruno Albuquerque wrote: >>>> >>>  >>> But, to complicate things, you can

Re: [go-nuts] Simple worker pool in golnag

as it is parallelizing the "all the clients work" - the Go program runs concurrently with other OS programs, but is parallelizing its own work.-Original Message- From: Jesper Louis Andersen Sent: Dec 30, 2019 3:41 PM To: Robert Engels Cc: Brian Candler , golang-nuts Subject: Re: [go-nu

Re: [go-nuts] Simple worker pool in golnag

on the underlying structures. So blindly creating go routines does not achieve optimum performance for many workloads (even when the number of OS threads is capped).rengels@rengels:~/gotest$ go run main_bench.go 2.261805812s1.311269725s6.341378965s-Original Message- From: Robert Engels Sent: Dec 30, 2019 9

Re: [go-nuts] Re: net.conn TCP connection

That option requires proprietary protocols not standard tcp/udp. > On Dec 30, 2019, at 12:04 PM, Bruno Albuquerque wrote: > >  > But, to complicate things, you can create what is basically a TCp connection > with packet boundaries using SOCK_SEQPACKET (as opposed to SOCK_STREAM or >

Re: [go-nuts] Re: net.conn TCP connection

ReadAll reads until buffer length or EOF. > On Dec 30, 2019, at 11:04 AM, Jake Montgomery wrote: > >  > It sounds like maybe you have some misconceptions about TCP. It is a stream > protocol, there are no data boundaries that are preserved. If send 20 bytes > via TCP in a single call, it is

Re: [go-nuts] Simple worker pool in golnag

Right, but the overhead is not constant nor free. So if you parallelize the CPU bound task into 100 segments and you only have 10 cores, the contention on the internal locking structures (scheduler, locks in channels) will be significant and the entire process will probably take far longer -

Re: [go-nuts] Re: net.conn TCP connection

Use read and expand the buffer as needed (or write the chunks to a file). If at the end it is all going to be in memory, you might as well start with the very large buffer. There is nothing special about Go in this regard - it’s standard IO processing. > On Dec 29, 2019, at 9:21 AM, Ron

Re: [go-nuts] Simple worker pool in golnag

easy create too many routines and then you are paying overhead switching costs for no reason. > On Dec 28, 2019, at 10:17 AM, Ian Lance Taylor wrote: > > On Sat, Dec 28, 2019 at 6:11 AM Robert Engels wrote: >> >> Spinning up a Go routine when for each piece of

Re: [go-nuts] Simple worker pool in golnag

Spinning up a Go routine when for each piece of work may be idiomatic but it is far from the best practice for many situations - mainly because of cpu cache invalidation. Most HPC systems create worker pools by type and then isolate them to cpus/cores - something you can’t do in Go. I believe

Re: [go-nuts] Re: net.conn TCP connection

The standard read will early return as soon as some of read is satisfied and a subsequent block would occur (or timeout) - so you have to decide when you want to stop reading... >> On Dec 27, 2019, at 9:48 PM, Robert Engels wrote: >  > You need a termination point. In the case o

Re: [go-nuts] Re: net.conn TCP connection

You need a termination point. In the case of ReadString it is the line terminator. For an arbitrary read it is either a length or EOF - or you can read until the underlying socket has no more data but this is generally useless unless you are doing higher level buffering and protocol parsing.

Re: [go-nuts] Simple worker pool in golnag

toCancelChan chan string) > { > defer wg.Done() > autoCancelIds := getAutoCancelIdsFromSource2() > for autoCancelId := range autoCancelIds { > autoCancelChan <- autoCancelId > } > } > > Now does this code makes some sense? > > >

Re: [go-nuts] Simple worker pool in golnag

Yes, the code doesn’t work :) - it will only ever produce 2 items - unless that was expected - even so, you want the N workers doing work, and probably a constant number sending to Kafka - but a lot depends on your “serial needs”. In your case you only have 2 workers producing work, and N

Re: [go-nuts] Now that wasm is 'standard'... bundle common lang runtimes with browsers

Pretty much the JVM in the browser all over again... if I can live long enough maybe I can see people touting the ergonomics and simplicity of the 3270. > On Dec 22, 2019, at 5:33 AM, 'Axel Wagner' via golang-nuts > wrote: > > ISTM that this requires being able to distribute the runtime of

Re: [go-nuts] cgo & long jump

That usage of setjmp and longjmp are pretty much banned in modern C by every linter. You can only call setjmp/longjmp within the current call stack (at least that's my understanding) - intermixing the context switch to Go would not be correct. Just have a wrapper on f2() that takes the

Re: [go-nuts] Help with Go channels and select talk

ttps://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14)" > >> On Sunday, December 8, 2019 at 7:18:16 AM UTC+1, Robert Engels wrote: >> I understand what you are saying but I’ll still suggest that your >> premise/design is not correct. There are plenty of useful

Re: [go-nuts] Help with Go channels and select talk

can't do something in Go, I wanted to ask here to make sure > I'm not missing something obvious. Basically, I intend to show how difficult > lock-free programming can be so don't force it - just use goroutines and > locks. > >> On Saturday, December 7, 2019 at 3

Re: [go-nuts] Help with Go channels and select talk

code nicer to read than 2_3.go > and 2_4.go. The extra goroutine that I'd like to be removed is started here: > https://github.com/egonk/chandemo/blob/master/1_1.go#L14 (line 14) > > What I mean by removed - no go statement, replaced presumably by some kind of > for/select combinat

Re: [go-nuts] Help with Go channels and select talk

comes up with a better implementation than 2_3.go and > 2_4.go, I would be very happy to include it in the talk. > > On Saturday, December 7, 2019 at 4:17:04 AM UTC+1, robert engels wrote: > To clarify, with Go’s very lightweight threads it is “doing the multiplexing > for you” -

Re: [go-nuts] Help with Go channels and select talk

async structures to do this well - Go doesn’t really support async by design - and it’s a much simpler programming model as a result. > On Dec 6, 2019, at 12:02 PM, Robert Engels wrote: > > A channel is much closer to a pipe. There are producers and consumers and > these are typical

Re: [go-nuts] Help with Go channels and select talk

es of course, just a single goroutine per > bidi channel seems hard. By contrast, I've worked with actor systems before > and they are perfectly fine with a single fiber. > >> On Friday, December 6, 2019 at 3:38:20 PM UTC+1, Robert Engels wrote: >> Channels are designed to

Re: [go-nuts] Inconsistent rounding with float printf ?

You can use github.com/robaho/fixed > On Dec 6, 2019, at 10:19 AM, Michael Jones wrote: > >  > Agree with Ian. > > Solutions are: change expectations, use decimal floating point, or use a > base-independent decimal representation. The latter implies scaled integers. > > Quick, ugly, and

Re: [go-nuts] Help with Go channels and select talk

Channels are designed to be used with multiple go routines - if you’re not you are doing something wrong. > On Dec 6, 2019, at 8:32 AM, Egon Kocjan wrote: > >  > Hello > > I'm preparing a short talk about Go channels and select. More specifically, I > want to show what not to do. I chose a

Re: [go-nuts] log may block the entire program if stderr pipe gets full

Nothing to be done here. This is the expected behavior and has been that way since the start of Unix. You can get around this by piping to an intermediate process that spools to disk and reads from that - until you run out of disk space. Honestly you probably should fix the consumer. > On

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

?On Tuesday, December 3, 2019 at 7:52:54 PM UTC-8, robert engels wrote:You actually only need a cas and a condition variable (technically the condition in Go requires a backing lock, but if you have wait/notify it isn’t needed).You can read this https://code.woboq.org/userspace/glibc/nptl

Re: [go-nuts] Re: Workaround for missing RWMutex.Try*Lock()

That pkg is not a RW lock though - it is an exclusive mutex. The pseudo code I provided is a RW try lock. > On Dec 4, 2019, at 4:49 AM, pierre.cu...@gmail.com wrote: > >  > This may be of relevance to you: > https://pkg.go.dev/gvisor.dev/gvisor/pkg/tmutex?tab=doc > > > Le mercredi 4

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

t that doesn't work for read-lock. > > On Tuesday, December 3, 2019 at 5:39:48 PM UTC-8, Robert Engels wrote: > It depends then, because technically the Go RW lock queues readers behind a > waiting writer so “busy” is somewhat undefined. If “busy” means “would block” > you can still do it - I’

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

It depends then, because technically the Go RW lock queues readers behind a waiting writer so “busy” is somewhat undefined. If “busy” means “would block” you can still do it - I’ll post the code tonight. > On Dec 3, 2019, at 6:49 PM, Robert Engels wrote: > > I would use an atomic a

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

Can’t code on the phone but a cas on the atomic then take the lock. But if you never need to block you don’t even need the lock. > On Dec 3, 2019, at 6:52 PM, Liam Breck wrote: > >  > Which looks like...? > >> On Tue, Dec 3, 2019, 4:50 PM Robert Engels wrote: >

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

I would use an atomic and a lock instead of two locks. > On Dec 3, 2019, at 6:35 PM, burak serdar wrote: > > On Tue, Dec 3, 2019 at 5:21 PM Liam Breck wrote: >> >> I have a problem that is trivially solved via >> >> door sync.RWMutex >> >> func Reader() T { >> if !door.TryRLock() { //

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