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

[Lutz Horn]

> 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 reasons like network issue, or they are rebooting
> etc.).  For now the master high availability is not a serious
> requirement. But would prefer a design that doesn't over complicate
> things when master HA has to be added. master and slaves are fully go
> code and unlikely to change.

Did you consider a system like RabbitMQ[0] as the messaging layer? It
supports all the features you describe including dynamic joining/leaving
of clients.

Client libraries for many languages exist[1], including Go[2].

Regards

Lutz

[0] https://www.rabbitmq.com/
[1] https://www.rabbitmq.com/devtools.html
[2] https://github.com/streadway/amqp

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tong Sun]

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, but it also loses enum typing... Depending on 
>> the enum, you may want to have different properties as well...
>> I chose the name "ciota" because of "custom-iota", in practice you would 
>> want something more descriptive such as "NewWeekday". 
>
>
> So the solution is easy, don't create a general purpose package for it :D
>>
>
> OK. 
>
> If going that route, and I have several enum series to define, I need to 
> define a series of almost identical functions, right? Hmm..., that'd be 
> really messy. 
>
> Ok, I'll think of a better way on my own, which I doubt I could, :-)
>

 
Thought I need to use reflection, but after several round of wrestling, I 
managed to do without reflection at all:


package main


import (
 "fmt"


 enum "github.com/suntong/enum"
)


var (
 example enum.Enum
 Alpha   = example.Iota("Alpha")
 Beta= example.Iota("Beta")


 weekday enum.Enum
 Sunday  = weekday.Iota("Sunday")
 Monday  = weekday.Iota("Monday")
)


func main() {
 fmt.Printf("%s\n", example.String(Alpha))
 fmt.Printf("%s\n", example.String(Beta))
 fmt.Println("===")
 fmt.Printf("%d\t%d\n", Alpha, Alpha+1)
 fmt.Printf("%s\t%s\n", example.String(Beta-1), example.String(Alpha+1))
 fmt.Println("===")
 if a, ok := example.Get("Alpha"); ok {
 fmt.Printf("%d: %s\n", a, example.String(a))
 }
 if b, ok := example.Get("Beta"); ok {
 fmt.Printf("%d: %+v\n", b, example.String(b))
 }


 fmt.Printf("%d:%s\n", Sunday, weekday.String(Sunday))
 fmt.Printf("%d:%s\n", Monday, weekday.String(Monday))
}


The output:

Alpha
Beta
===
0   1
Alpha   Beta
===
0: Alpha
1: Beta
0:Sunday
1:Monday

Ref: 

https://github.com/suntong/lang/blob/master/lang/Go/src/ds/EnumsStr1p.go

and

https://github.com/suntong/enum


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Oracle db and panics on interrupt

[pierre . curto]

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 
. Of course an Oracle instance and 
libs are required for it to work.

Should it be reported to the maintainers of the Oracle package or the Go 
team?
It seems to me it should be the later, but I want to make sure.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Phillips]

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 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
> reasons like network issue, or they are rebooting etc.).  For now the
> master high availability is not a serious requirement. But would prefer a
> design that doesn't over complicate things when master HA has to be added.
> master and slaves are fully go code and unlikely to change.
>
> options I am considering are..
>
> 1. workers connect to the master over TCP. Master writes the event to a
> consistent store like etcd or consul. All the workers would setup a watch
> on the store and go read it themselves. I don't know how well the watch
> approach will scale as the number of workers increase.
>
> 2. workers connect to the master over TCP. Master uses a gossip mechanism
> to send the event (for ex: using serf). This has the drawback that some
> clients can receive the event much later others. But will scale better than
> approach 1. This approach needs some form of reconciliation when a worker
> reboots because it could have missed some events when it was down or
> rebooting.
>
> 3. workers connect to the master over TCP. Master on getting an event from
> worker 1 sends it over the TCP to all other workers. This needs lot of
> 'reinventing the wheel' to guarantee that all workers get the event.
>
> Looking for suggestions for other approaches (message broker ? pubsub ?)
> using open source go packages for this requirement. Thanks.
>
> Manohar.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sam Whited]

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 yet another stack frame allocation
you can always wrap your lock/unlock (or file close or whatever) and
logic in an anonymous closure. This of course may not be appropriate
for all situations, and isn't especially nice looking; anytime I find
myself doing this my general reaction is that I need to refactor so
that it's not necessary.

>   func() {
> m.Lock()
> defer m.Unlock()
>
> // Do some stuff
>   }()
>   // …
>   // outer function end
> }


—Sam

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Thomas Bushnell, BSG' via golang-nuts]

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
> , if
> you want to know), because the knowledge is related thus better keep in one
> demo file instead of several. However, the challenge to me is that, it
> keeps reusing the same variable name for different purposes (which I think
> IS good practice). E.g.,
>
> In one section the type A is defined as
>
> type A struct {
> }
>
> In another section the type A is defined as
>
> type A struct {
> name string
> }
>
>
> In C#, this is not a problem at all, as I can just put different cases
> into different namespaces.
>
> How to do it (putting different code collection into the same Go source
> file) in Go?
>
> I tried to separate different sections with
>
> package next_section
>
> but got the error
>
> expected declaration, found 'package'
>
> What's the easiest way to do it? please help.
>
> Thanks
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 Unlock, ie Unlock happens not at function exit, but is triggered
> asynchronously
> by some condition.
> More: if you panic cause you already found state inconsistent, then there
> is
> no way to fix it, cause most likely you don't know how it became
> inconsistent.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 found state inconsistent, then there is
no way to fix it, cause most likely you don't know how it became
inconsistent.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jan Mercl]

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 long-running goroutine from acquiring that mutex.

Code bug: Don't Lock without defer Unlock(). (I'm a sinner, just telling
what I learned.)

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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 - made worse because I'd forgotten that
the stdlib recovers from panics in HTTP requests by default...

This is the kind of subtle problem that makes me think that recovering
from panics as a way of making the system more reliable can actually lead
to nastier problems further down the line.


On 26 April 2017 at 10:38, 'Axel Wagner' via golang-nuts
 wrote:
> 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 the
 use of recovering from a panic to assist (emphasis on assist - it is
 certainly no silver bullet) in achieving fault tolerance.

 Assuming a web service that needs to be highly available, crashing the
 entire process due to one misbehaved goroutine is irresponsible.  There can
 be thousands of other active requests in flight that could fail gracefully
 as well, or succeed at their task.

 In this scenario, I believe a well behaved program should

 clearly log all information about the fault
>>>
>>> panic does that
>>
>>
>> No, panic certainly does not do that. It prints the stack trace. A proper
>> logger could add additional information about the program state at the point
>> of the panic, which is not visible from the stack trace. It also might at
>> least be reasonable to perform an auto-save before quitting.
>>
>>> Same; relying on a malfunctioning program to report its failure is like
>>> asking a sick human to perform their own surgery.
>>
>>
>> What makes you think that a panic implies that the whole program is
>> malfunctioning?
>
>
> But that is not the claim. The claim is, that if you discover a condition
> which can uniquely be attributed to a code bug, you should always err on the
> side of safety and prefer bailing out to continuing with a known-bad
> program. It's not "as I see this bug, I know the rest of the program is
> broken too", it's "as I see this bug, I can not pretend that it can't be".
>
>>
>> A panic should certainly taken seriously, and the computation in which it
>> happened should be aborted. But if you think of a functional programming
>> style
>
>
> If you are thinking of that, then you are not thinking about go. Go has
> shared state and mutable data. One of the major arguments here is, that
> there is a level of isolation of state, which is very good, from all we
> know, and that's the process; if the process dies, all locks are being
> released, file descriptors closed and memory freed, so it gives a known-good
> re-starting point. And that, in the presence of mutable state, potential
> data races and code bugs, that is the correct layer of isolation to fall
> back to. And I am also aware, that it's also not a perfect layer; you might
> have already corrupted on-disk state or abused a protocol to corrupt some
> state on the network. Those also need to be defended against, but process
> isolation still gives a good tradeoff between efficiency, convenience and
> safety.
>
>
> FWIW, I don't believe there is any convincing to be done here on either
> side. There are no technical arguments anymore; it is just that one set of
> people are holding one belief and another set of people are holding another
> belief. Both certainly do that based on technical arguments, but in the end,
> they are simply weighing them differently.
>
> I mean, I definitely agree that it would be great for a program to never
> crash. Or to have only panics which definitely can't be recovered from. Or
> to have all state isolated and safely expungeable. I agree, that the process
> being up for a larger timeslice is valuable and that other requests
> shouldn't fail because one of them misbehaved.
>
> I also assume you agree that errors should be noticed, caught and fixed. I
> assume you agree that crashing a binary will make the bug more noticeable.
> That crashing would allow you to recover from a safer and better-known
> state. And that being able to recover from any crash swiftly and
> architecting a service so that processes dying doesn't take it down is
> valuable and bugs shouldn't make it to production.
>
> The facts are straight, this is just a question of opinion and different
> experiences; and I don't see any way out of it than saying "agree to
> disagree; if you don't think you can tolerate panic's, you just can't use my
> stuff and I won't use yours, if I consider it to hide failures or be
> unergonomic".
> This argument becomes much more difficult, when I'm having it 

Re: [go-nuts] bytes.Buffer WriteAt

[Jan Mercl]

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:
https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/file/file.go#L49
A file cache is just above it. Not importable so you need to copy/paste any
code if you want to play with it.



-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: bytes.Buffer WriteAt

[Chris Hopkins]

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 implementing a file cache and using a bytes.Buffer in my 
> testbench as a model of a perfect file.
> One slight imperfection, the standard bytes.Buffer does not implement 
> WriteAt which I find a little odd as it does implement ReadAt.
> Now this is easy enough to work around, but I wondered if anyone knew the 
> thinking behind it? Is it just no-one has bothered implementing it yet (I 
> find this surprising) or am I missing something subtle here? If no-one has 
> bothered implementing it, should I be publishing my workaround for future 
> inclusion?
>
> Background:
> All the caches I've found so far seem based around http. Whereas I'm 
> dealing with a large (pair of) file(s) that I expect to be accessing a 
> small portion of, so a per file cache that caches read and write accesses 
> seems like a really obvious thing to use. However I cannot find anyone else 
> having written something similar. I guess people are just relying on the 
> file system to do this for them.
>
> Thanks
>
> Chris
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Axel Wagner' via golang-nuts]

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 the
>>> use of recovering from a panic to assist (emphasis on assist - it is
>>> certainly no silver bullet) in achieving fault tolerance.
>>>
>>> Assuming a web service that needs to be highly available, crashing the
>>> entire process due to one misbehaved goroutine is irresponsible.  There can
>>> be thousands of other active requests in flight that could fail gracefully
>>> as well, or succeed at their task.
>>>
>>> In this scenario, I believe a well behaved program should
>>>
>>>- clearly log all information about the fault
>>>
>>> panic does that
>>
>
> No, panic certainly does not do that. It prints the stack trace. A proper
> logger could add additional information about the program state at the
> point of the panic, which is not visible from the stack trace. It also
> might at least be reasonable to perform an auto-save before quitting.
>
> Same; relying on a malfunctioning program to report its failure is like
>> asking a sick human to perform their own surgery.
>>
>
> What makes you think that a panic implies that the whole program is
> malfunctioning?
>

But *that is not the claim*. The claim is, that if you discover a condition
which can uniquely be attributed to a code bug, you should always err on
the side of safety and prefer bailing out to continuing with a known-bad
program. It's not "as I see this bug, I know the rest of the program is
broken too", it's "as I see this bug, I can not pretend that it can't be".


> A panic should certainly taken seriously, and the computation in which it
> happened should be aborted. But if you think of a functional programming
> style
>

If you are thinking of that, then you are not thinking about go. Go has
shared state and mutable data. One of the major arguments here is, that
there is a level of isolation of state, which is very good, from all we
know, and that's the process; if the process dies, all locks are being
released, file descriptors closed and memory freed, so it gives a
known-good re-starting point. And that, in the presence of mutable state,
potential data races and code bugs, that is the correct layer of isolation
to fall back to. And I am also aware, that it's also not a perfect layer;
you might have already corrupted on-disk state or abused a protocol to
corrupt some state on the network. Those also need to be defended against,
but process isolation still gives a good tradeoff between efficiency,
convenience and safety.


FWIW, I don't believe there is any convincing to be done here on either
side. There are no technical arguments anymore; it is just that one set of
people are holding one belief and another set of people are holding another
belief. Both certainly do that based on technical arguments, but in the
end, they are simply weighing them differently.

I mean, I definitely agree that it would be great for a program to never
crash. Or to have only panics which definitely can't be recovered from. Or
to have all state isolated and safely expungeable. I agree, that the
process being up for a larger timeslice is valuable and that other requests
shouldn't fail because one of them misbehaved.

I also assume you agree that errors should be noticed, caught and fixed. I
assume you agree that crashing a binary will make the bug more noticeable.
That crashing would allow you to recover from a safer and better-known
state. And that being able to recover from any crash swiftly and
architecting a service so that processes dying doesn't take it down is
valuable and bugs shouldn't make it to production.

The facts are straight, this is just a question of opinion and different
experiences; and I don't see any way out of it than saying "agree to
disagree; if you don't think you can tolerate panic's, you just can't use
my stuff and I won't use yours, if I consider it to hide failures or be
unergonomic".
This argument becomes much more difficult, when I'm having it with my
coworkers, as it *does* depend on how the service is run, which needs to be
decided by the team; in regards to this thread, at least we all have the
luxury that we can agree to disagree and move on :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[hui zhang]

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
command-line-arguments

在 2017年4月26日星期三 UTC+8下午4:37:38，hui zhang写道：
>
> 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)
>
> Target: x86_64-apple-darwin15.5.0
>
> Thread model: posix
>
> any workaround ?
>
>
> 在 2017年4月26日星期三 UTC+8下午3:59:15，hui zhang写道：
>>
>> 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日星期三 UTC+8下午3:20:14，hui zhang写道：
>>>
>>> Check code below
>>> go call c opengl/opengles code,   typedef void GLvoid
>>>
>>> func GenVertexArrays(n int32, arrays *uint32) {
>>>//C.glGenVertexArrays((C.GLsizei)(n), 
>>> (*C.GLuint)(unsafe.Pointer(arrays)))  --> ok on darwin amd64
>>>C.glGenVertexArraysOES((C.GLsizei)(n), 
>>> (*C.GLuint)(unsafe.Pointer(arrays))) --> fail on darwin arm
>>> }
>>>
>>> Error Message
>>>
>>> cgo-gcc-prolog:36:10: error: field has incomplete type 'GLvoid' (aka 
>>> 'void')
>>> For the GLvoid(aka void)  can not be understood by cgo
>>>
>>> function decalred
>>> void *glGenVertexArrays*(GLsizei n, GLuint *arrays); -->on darwin amd64 
>>> opengl
>>>
>>> GLvoid glGenVertexArraysOES(GLsizei n, GLuint *arrays) -->on darwin arm 
>>> opengles
>>>
>>>
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Herth]

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 no silver bullet) in achieving fault tolerance.
>>
>> Assuming a web service that needs to be highly available, crashing the
>> entire process due to one misbehaved goroutine is irresponsible.  There can
>> be thousands of other active requests in flight that could fail gracefully
>> as well, or succeed at their task.
>>
>> In this scenario, I believe a well behaved program should
>>
>>- clearly log all information about the fault
>>
>> panic does that
>

No, panic certainly does not do that. It prints the stack trace. A proper
logger could add additional information about the program state at the
point of the panic, which is not visible from the stack trace. It also
might at least be reasonable to perform an auto-save before quitting.

Same; relying on a malfunctioning program to report its failure is like
> asking a sick human to perform their own surgery.
>

What makes you think that a panic implies that the whole program is
malfunctioning? A panic should certainly taken seriously, and the
computation in which it happened should be aborted. But if you think of a
functional programming style, there are clear points in the call tree, at
which the recover could happen and the the computation can safely aborted
without impacting the rest of the program. If you think of any multi-user
software, at worst you can kill the session for a user, but do not
necessarily have to impact the other users.

Best regards,
Peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[hui zhang]

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)

Target: x86_64-apple-darwin15.5.0

Thread model: posix

any workaround ?


在 2017年4月26日星期三 UTC+8下午3:59:15，hui zhang写道：
>
> 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日星期三 UTC+8下午3:20:14，hui zhang写道：
>>
>> Check code below
>> go call c opengl/opengles code,   typedef void GLvoid
>>
>> func GenVertexArrays(n int32, arrays *uint32) {
>>//C.glGenVertexArrays((C.GLsizei)(n), 
>> (*C.GLuint)(unsafe.Pointer(arrays)))  --> ok on darwin amd64
>>C.glGenVertexArraysOES((C.GLsizei)(n), 
>> (*C.GLuint)(unsafe.Pointer(arrays))) --> fail on darwin arm
>> }
>>
>> Error Message
>>
>> cgo-gcc-prolog:36:10: error: field has incomplete type 'GLvoid' (aka 
>> 'void')
>> For the GLvoid(aka void)  can not be understood by cgo
>>
>> function decalred
>> void *glGenVertexArrays*(GLsizei n, GLuint *arrays); -->on darwin amd64 
>> opengl
>>
>> GLvoid glGenVertexArraysOES(GLsizei n, GLuint *arrays) -->on darwin arm 
>> opengles
>>
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[hui zhang]

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日星期三 UTC+8下午3:20:14，hui zhang写道：
>
> Check code below
> go call c opengl/opengles code,   typedef void GLvoid
>
> func GenVertexArrays(n int32, arrays *uint32) {
>//C.glGenVertexArrays((C.GLsizei)(n), (*C.GLuint)(unsafe.Pointer(arrays))) 
>  --> ok on darwin amd64
>C.glGenVertexArraysOES((C.GLsizei)(n), 
> (*C.GLuint)(unsafe.Pointer(arrays))) --> fail on darwin arm
> }
>
> Error Message
>
> cgo-gcc-prolog:36:10: error: field has incomplete type 'GLvoid' (aka 
> 'void')
> For the GLvoid(aka void)  can not be understood by cgo
>
> function decalred
> void *glGenVertexArrays*(GLsizei n, GLuint *arrays); -->on darwin amd64 
> opengl
>
> GLvoid glGenVertexArraysOES(GLsizei n, GLuint *arrays) -->on darwin arm 
> opengles
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 state or
input", "fast control flow" and "fatal" errors.
C has "return code + errno" for first, "setjmp/longjmp" for second and
"assert" for third.
Languages with exceptions have exceptions hierarhy with documented support
from runtime for "fatal exceptions".

Some languages choose process isolation for recovering from fatal error
(php, erlang... .Net has domains, but looks like .Ney Core doesn't).

Go has "return error" for first, abuses "panic/recover" for second, and in
absence of true process isolation, simply has no choice for "fatal error".

Go should have choice for "fatal error". Since many people want to recover
from "fatal error" (and this thread shows it clearly), Go should have true
"process isolation".

But it is just a dream.

26 апр. 2017 г. 8:35 AM пользователь "Bakul Shah" 
написал:

> Recover/panic need not be used *only* in case of a “critical” error. Just
> as in the case of setjmp/longjmp, there are other useful patterns. For
> example, a user may ask an interpreter to abandon its current computation
> by typing  ^C. This would be handled by a longjmp/panic() to *regain*
> control at the REPL level.
>
> There are actually at least three use cases:
> 1. Reduce the "semantic clutter" of having to check error return at every
> level just because a very deeply nested function may fail
> 2. Regain control as above in case of cancellation.
> 3. Indicate a critical error.
>
> For 1. (IMHO) the best mechanism was Pascal’s non-local goto. It *only*
> returned control higher up in the stack and to a lexically enclosing
> function - this could be checked at compile time. In Go panic/recover are
> analogs of longjmp/setjump and compile time checking is not possible to
> ensure that panic doen’t escape a package scope. Also, Go allows lexical
> nesting of unnamed functions but not named ones so one would not write,
> e.g. a parse() function as one giant function with multiple sub functions,
> one each for a parse rule. And concurrency complicates things.
>
> On Apr 25, 2017, at 7:52 PM, Dave Cheney  wrote:
>
> Yes, and then crashes the program. In the scenario I described, with
> thousands of other requests in flight that meet an abrubt end.  That could
> be incredibly costly, even if it's been planned for
>
>
> There are a host of other reasons that can take a server offline abruptly.
> It seems like a odd misallocation of resources to try to prevent one
> specific case - a goroutine panics due to a programming error or input
> validation failure -- both which are far better addressed with testing.
>
> To try to postpone the exit of a program after a critical error to me
> implies a much more complex testing and validation process that has
> identified all the shared state in the program and verified that it is
> correct in the case that a panic is caught.
>
> To me it seems simpler and more likely to have the root cause of the panic
> addressed to just let the program crash. The alternative, somehow
> firewalling the crash, and its effects on the internal state of your
> program, sounds unworkably optimistic.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rW6LB-9N37I/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.