Thanks!
On Sunday, April 14, 2019 at 3:28:59 AM UTC+3, al...@alrux.com wrote:
>
> While the expected r/w patterns will certainly influence the amount of
> pain you may feel from using "global state", I would not consider it to be
> the main deciding factor.
>
> Now, please keep in mind that this
:)
Can't believe the book is named with "Golang"!
dharani
On Sun, Apr 14, 2019 at 5:12 PM Rob Pike wrote:
> Bhagvan: Please note that the language is called Go, not Golang.
>
> -rob
>
>
>
> On Mon, Apr 15, 2019 at 1:49 AM Robert Solomon wrote:
>
>> I actually find it useful to have these pos
Bhagvan: Please note that the language is called Go, not Golang.
-rob
On Mon, Apr 15, 2019 at 1:49 AM Robert Solomon wrote:
> I actually find it useful to have these posted here. I'm a notice Go
> programmer, and these references help me.
> I also saw a reference to "Hands On GUI Application
I believe you only need one or the other; I assumed a use case like this:
https://play.golang.org/p/nSgyiXU87XN
On Sun, Apr 14, 2019 at 1:33 PM wrote:
> I found a good discussion in the FAQ that explains the problem clearly.
> https://golang.org/doc/faq#methods_on_values_or_pointers
>
> I thin
On Sunday, April 14, 2019 at 10:18:00 PM UTC+12, shrin...@gmail.com wrote:
>
> which is best thrift client pooling driver supported in golang (means
> which is optimized according to performance )
>
Do any of them even do client pooling? I would be interested to know. I've
had to handle my own
SHA256 (SHA in general) has a precise behavior if you wanna hash a number
of bits not multiple of the block (512bit)
Sha256.go handle this correcty ONLY in the case that you input is at least
multiple of 8 bits.
If you wanna hash, say, 20bit (0xABCDE) you cannot obtain a correct result.
Note that
On Sunday, April 14, 2019 at 8:16:11 PM UTC+2, Matt Harden wrote:
>
> No, you don't need sync/atomic. The mutex is sufficient. By the way, you
> should put the mutex inside of guardedState, next to the data being
> guarded. Had you done that originally, Go Vet would have complained about
> you p
I found a good discussion in the FAQ that explains the problem clearly.
https://golang.org/doc/faq#methods_on_values_or_pointers
I think the mutex is needed on the update function with or without the use
of sync/atomic. The atomic guards the Load and the Store but the func is
operating on the
Good to know about not needing sync/atomic. I used a pointer to an
externally defined mutex because an answer I found on StackOverflow
recommended doing that. However, on looking at my application more closely
I think you're right about putting it inside the struct.
On Sunday, April 14, 2019
Sorry it took so long for this post, other things intervened. Anyway, quick
responses to the three people who commented.
Shulhan, there is a better mechanism in Go than resetting the buffer. Have
a second variable, say "var message []byte", and then after the call to
ReadMsgUDP add this line "m
I don't know if it's documented or not. In the language reference you can
see the rules for method calls:
https://golang.org/ref/spec#Calls
https://golang.org/ref/spec#Method_sets
A hint might have been that object should have mutated, but it didn't.
It's in a class of errors that becomes recogn
No, you don't need sync/atomic. The mutex is sufficient. By the way, you
should put the mutex inside of guardedState, next to the data being
guarded. Had you done that originally, Go Vet would have complained about
you passing guardedState by value (mutexes should never by copied).
https://play.go
Thanks, Skip. That fixes it. Is the need for a pointer receiver documented
somewhere? It's not something that even crossed my mind given that the
neither the compiler nor golint complained. I suppose it makes sense if I
think of func (x) foo(y) {} as being an alternate way of writing func
foo(
The receiver for load and update should be the original object not a copy.
https://play.golang.org/p/XCZC0OVhGMa
On Sun, Apr 14, 2019, 7:56 AM wrote:
>
> https://play.golang.org/p/6aQYNjojyBD
>
> I'm clearly missing something about the way sync.Mutex and atomic.Value
> work in Go.
>
> I'm attem
I actually find it useful to have these posted here. I'm a notice Go
programmer, and these references help me.
I also saw a reference to "Hands On GUI Application Development in Go,"
which I'm starting to read now.
On Friday, April 5, 2019 at 10:28:52 AM UTC-4, Bhagvan Kommadi wrote:
>
> Check
https://play.golang.org/p/6aQYNjojyBD
I'm clearly missing something about the way sync.Mutex and atomic.Value
work in Go.
I'm attempting to write a pair of concurrency safe methods, load() and
update(), for accessing a struct. The struct is stored as an atomic.Value
and accessed with atomic.
In Go, you can simply create a CreateDatabase() function which initializes
your prepared statements, in lieu of the constructor.
When doing a SQL query, you must use the correct prepared statement for it,
so whether you have an array of them, or each is its own field, each
handler would have to us
Hi Marcin,
I know about Prepare function supported by sql package .My initial question
was what is better way to pass multiple prepare statements on different
http handlers .
ex: we can construct struct like this
type Database struct {
db *sql.DB
someStmt *sql.Stmt
// etc.
}
but sinc
which is best thrift client pooling driver supported in golang (means which
is optimized according to performance )
--
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
19 matches
Mail list logo
