Re: [go-nuts] master to slave communication - design suggestions

> I am working on building a distributed system where a bunch of > workers (can scale to few thousands) are connected to a manager. > Workers send certain local events to the manager and the manager then > should broadcast that event to all other workers. Workers shouldn't > miss any event (for

Re: [go-nuts] Re: Assign a string representation to an enum/const

On Tuesday, April 25, 2017 at 4:25:14 PM UTC-4, Tong Sun wrote: > > > On Tue, Apr 25, 2017 at 3:42 PM, Egon wrote: > > I think the extra "enum" package would reduce readability. The code you >> are putting into package is ~10 lines of code... so the extra package >> doesn't reduce much typing,

[go-nuts] Oracle db and panics on interrupt

Hello, I am unsure where to log the following issue: whenever I send an interrupt signal to a go process running an Oracle query, it panics with either "fatal: morestack on g0" or "fatal error: runtime: stack split at bad time". A sample code reproducing the issue is here

Re: [go-nuts] master to slave communication - design suggestions

Hey Manohar, Sounds like this could be simplified by using Kafka as an event bus. Kafka is horizontally scalable and the Sarama golang library is excellent. Regards, Ryan On Wed, Apr 26, 2017 at 11:33 AM, Manohar Kumar wrote: > Hello, > > I am working on building a

Re: [go-nuts] Re: Recover considered harmful

On Wed, Apr 26, 2017 at 10:47 AM, Юрий Соколов wrote: > You are not quite right. Sometimes there is scope dependency between Lock > and Unlock, ie Unlock happens not at function exit, but is triggered > asynchronously by some condition. If you can stomach the overhead of

Re: [go-nuts] Expected declaration, found 'package'

A single Go source file is not allowed to be in more than one package. On Wed, Apr 26, 2017 at 8:52 AM Tong Sun wrote: > Hi, > > I'm trying to put different code collection into the same Go source file, > (from here >

Re: [go-nuts] Re: Recover considered harmful

s/there is scope dependency/there is no scope dependency/ 2017-04-26 18:47 GMT+03:00 Юрий Соколов : > > Don't Lock without defer Unlock(). (I'm a sinner, just telling what I > learned.) > > You are not quite right. Sometimes there is scope dependency between Lock > and

Re: [go-nuts] Re: Recover considered harmful

> Don't Lock without defer Unlock(). (I'm a sinner, just telling what I learned.) You are not quite right. Sometimes there is scope dependency between Lock and Unlock, ie Unlock happens not at function exit, but is triggered asynchronously by some condition. More: if you panic cause you already

Re: [go-nuts] Re: Recover considered harmful

On Wed, Apr 26, 2017 at 11:58 AM roger peppe wrote: > FWIW I have seen real problems in production where long-running worker goroutines stopped working. We looked into it and found that certain rare requests were panicking, not releasing a mutex and thus preventing the

Re: [go-nuts] Re: Recover considered harmful

FWIW I have seen real problems in production where long-running worker goroutines stopped working. We looked into it and found that certain rare requests were panicking, not releasing a mutex and thus preventing the long-running goroutine from acquiring that mutex. This took ages to work out -

Re: [go-nuts] bytes.Buffer WriteAt

On Wed, Apr 26, 2017 at 11:21 AM Chris Hopkins wrote: > However I cannot find anyone else having written something similar. FWIW, a [memory] cache with file os.File-like interface:

[go-nuts] Re: bytes.Buffer WriteAt

Apologies for replying to myself. Digging into the source it looks like I had misunderstood the purpose/functionality of bytes.Buffer. Sorry. Please ignore/delete the question. On Wednesday, 26 April 2017 10:21:10 UTC+1, Chris Hopkins wrote: > > Hi, > Random question: > I'm just starting

Re: [go-nuts] Re: Recover considered harmful

On Wed, Apr 26, 2017 at 10:55 AM, Peter Herth wrote: > > > On Wed, Apr 26, 2017 at 3:07 AM, Dave Cheney wrote: > >> >> >> On Wednesday, 26 April 2017 10:57:58 UTC+10, Chris G wrote: >>> >>> I think those are all excellent things to do. They do not preclude

[go-nuts] Re: void type alias can not be understood in cgo

Is this bug in cgo or in clang for gcc runs well ? CC=clang CGO_ENABLE=1 go build -v void.go -->fail command-line-arguments # command-line-arguments ./void.go:47:10: error: field has incomplete type 'GLvoid' (aka 'void') CC=gcc CGO_ENABLE=1 go build -o void -v void.go -->ok

Re: [go-nuts] Re: Recover considered harmful

On Wed, Apr 26, 2017 at 3:07 AM, Dave Cheney wrote: > > > On Wednesday, 26 April 2017 10:57:58 UTC+10, Chris G wrote: >> >> I think those are all excellent things to do. They do not preclude the >> use of recovering from a panic to assist (emphasis on assist - it is >> certainly

[go-nuts] Re: void type alias can not be understood in cgo

this code runs well on ubuntu gcc --version gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005 but build fail on mac gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.0.0 (clang-800.0.42.1)

[go-nuts] Re: void type alias can not be understood in cgo

I simply the case as below , how to fix it? package main /* #include #include typedef void GLvoid; GLvoid Foo() { printf("foo"); } */ import "C" func main() { C.Foo() } go build void.go cgo-gcc-prolog:34:10: error: field has incomplete type 'GLvoid' (aka 'void') 在 2017年4月26日星期三

Re: [go-nuts] Re: Recover considered harmful

`panic/recover` are really bad names for setjmp/longjmp. `throw/catch` are much closer. And C has `assert`. You may set handler for SIGABRT, but then you have to know what are you doing. Usually it is set for backtrace printing only. I mean: usual languages has clean separation between "wrong