FAQ
Need to get private number of open connections - is it possible to add
getter for this number?
Didn't find any other solution. May be just to add somrthing like this?

  diff --git a/src/database/sql/sql.go b/src/database/sql/sql.go
index 1ce679d..1b6972f 100644
--- a/src/database/sql/sql.go
+++ b/src/database/sql/sql.go
@@ -1011,6 +1011,11 @@ func (db *DB) Driver() driver.Driver {
         return db.driver
  }

+// Get returns the number of open connections.
+func (db *DB) GetNumOpen() int {
+ return db.numOpen
+}
+

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Marko at Feb 12, 2015 at 8:48 am
    You can't look at numOpen without holding db.mu. But the feature itself
    seems useful.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Алекс М at Feb 13, 2015 at 2:45 am
    Yes, more correct version will be:

    +// Get returns the number of open connections.
    +func (db *DB) GetNumOpen() int {
    + db.mu.Lock()
    + n := db.numOpen
    + db.mu.Unlock()
    + return n
    +}
    +

    четверг, 12 февраля 2015 г., 15:48:39 UTC+7 пользователь ma...@joh.to
    написал:
    You can't look at numOpen without holding db.mu. But the feature itself
    seems useful.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Marko at Feb 13, 2015 at 1:02 pm
    To get this accepted to the project, you have to create a "change" in
    Gerrit. See the documentation here: https://golang.org/doc/contribute.html


    .m

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alexander Milyutin at Feb 16, 2015 at 10:45 am
    Guys, how to ask someone capable to review this change?
    https://go-review.googlesource.com/#/c/4942/
    On Friday, February 13, 2015 at 8:02:00 PM UTC+7, Marko Tiikkaja wrote:

    To get this accepted to the project, you have to create a "change" in
    Gerrit. See the documentation here:
    https://golang.org/doc/contribute.html


    .m
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Benjamin Measures at Feb 16, 2015 at 11:28 am

    On Monday, 16 February 2015 10:45:53 UTC, Alexander Milyutin wrote:
    Guys, how to ask someone capable to review this change?
    https://go-review.googlesource.com/#/c/4942/
    <https://golang.org/doc/effective_go.html#Getters>:
    it's neither idiomatic nor necessary to put Get into the getter's name.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Feb 13, 2015 at 3:25 pm

    On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to wrote:
    You can't look at numOpen without holding db.mu. But the feature itself
    seems useful.
    Sure you can. You're not allowed to just read the value, according to Go's
    memory model, but you can use sync/atomic to get around that and do a
    "racy" read. It's not less correct that the locked approach, since either
    way by the time your code uses the returned value you're not holding any
    mutex and it can be stale. Databases, operating systems kernels, etc
    frequently use that tactic. All that having been said, the performance
    difference isn't likely to matter here and the intention is clearer with
    the mutex (and less likely to trigger a warning from the race checker.)

    Cheers,
    Dan

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Marko Tiikkaja at Feb 13, 2015 at 3:35 pm

    On 2/13/15 4:25 PM, Daniel Eloff wrote:
    On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to wrote:

    You can't look at numOpen without holding db.mu. But the feature itself
    seems useful.
    Sure you can. You're not allowed to just read the value, according to Go's
    memory model, but you can use sync/atomic to get around that and do a
    "racy" read. It's not less correct that the locked approach, since either
    way by the time your code uses the returned value you're not holding any
    mutex and it can be stale.
    OK. But looks like race checker (like you guessed) will complain
    *immediately*. So it still doesn't seem like a terribly good idea.


    .m

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Feb 13, 2015 at 5:20 pm
    Yes, it should, because it is a race condition, and the race checker can't
    know it's harmless in this case. I wouldn't do it unless performance was a
    real problem, and I just don't see it being a problem with this code. I'd
    stick with the mutex.
    On Friday, February 13, 2015 at 10:35:35 AM UTC-5, Marko Tiikkaja wrote:
    On 2/13/15 4:25 PM, Daniel Eloff wrote:
    On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to wrote:

    You can't look at numOpen without holding db.mu. But the feature
    itself
    seems useful.
    Sure you can. You're not allowed to just read the value, according to Go's
    memory model, but you can use sync/atomic to get around that and do a
    "racy" read. It's not less correct that the locked approach, since either
    way by the time your code uses the returned value you're not holding any
    mutex and it can be stale.
    OK. But looks like race checker (like you guessed) will complain
    *immediately*. So it still doesn't seem like a terribly good idea.


    .m
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Niko Schwarz at Feb 14, 2015 at 8:25 am
    I haven't yet seen a harmless data race.

    Niko
    On Friday, February 13, 2015 at 6:20:45 PM UTC+1, Daniel Eloff wrote:

    Yes, it should, because it is a race condition, and the race checker can't
    know it's harmless in this case. I wouldn't do it unless performance was a
    real problem, and I just don't see it being a problem with this code. I'd
    stick with the mutex.
    On Friday, February 13, 2015 at 10:35:35 AM UTC-5, Marko Tiikkaja wrote:
    On 2/13/15 4:25 PM, Daniel Eloff wrote:
    On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to
    wrote:
    You can't look at numOpen without holding db.mu. But the feature
    itself
    seems useful.
    Sure you can. You're not allowed to just read the value, according to Go's
    memory model, but you can use sync/atomic to get around that and do a
    "racy" read. It's not less correct that the locked approach, since either
    way by the time your code uses the returned value you're not holding any
    mutex and it can be stale.
    OK. But looks like race checker (like you guessed) will complain
    *immediately*. So it still doesn't seem like a terribly good idea.


    .m
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Feb 14, 2015 at 3:31 pm
    Yes you have, because I just pointed one out in this thread. If you want
    more examples, have a look at the linux kernel or postgresql or the java
    hotspot compiler. Harmless meaning that the system behaves as intended with
    the data race, e.g. it reads stale data but that doesn't matter. There are
    even harmless write data races, e.g. sometimes some kinds of performance
    counters are not synchronized. This means they might lose updates during
    contention, but the system continues to operate fine with approximate
    values. Unless I am mistaken, hotspot does this in deciding what function
    is hot enough to compile.

    Cheers,
    Dan
    On Saturday, February 14, 2015 at 3:25:31 AM UTC-5, Niko Schwarz wrote:

    I haven't yet seen a harmless data race.

    Niko
    On Friday, February 13, 2015 at 6:20:45 PM UTC+1, Daniel Eloff wrote:

    Yes, it should, because it is a race condition, and the race checker
    can't know it's harmless in this case. I wouldn't do it unless performance
    was a real problem, and I just don't see it being a problem with this code.
    I'd stick with the mutex.
    On Friday, February 13, 2015 at 10:35:35 AM UTC-5, Marko Tiikkaja wrote:
    On 2/13/15 4:25 PM, Daniel Eloff wrote:
    On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to
    wrote:
    You can't look at numOpen without holding db.mu. But the feature
    itself
    seems useful.
    Sure you can. You're not allowed to just read the value, according to Go's
    memory model, but you can use sync/atomic to get around that and do a
    "racy" read. It's not less correct that the locked approach, since either
    way by the time your code uses the returned value you're not holding any
    mutex and it can be stale.
    OK. But looks like race checker (like you guessed) will complain
    *immediately*. So it still doesn't seem like a terribly good idea.


    .m
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Martin Schnabel at Feb 14, 2015 at 6:22 pm

    On 02/14/2015 04:31 PM, Daniel Eloff wrote:
    Yes you have, because I just pointed one out in this thread. If you want
    more examples, have a look at the linux kernel or postgresql or the java
    hotspot compiler. Harmless meaning that the system behaves as intended
    with the data race, e.g. it reads stale data but that doesn't matter.
    There are even harmless write data races, e.g. sometimes some kinds of
    performance counters are not synchronized. This means they might lose
    updates during contention, but the system continues to operate fine with
    approximate values. Unless I am mistaken, hotspot does this in deciding
    what function is hot enough to compile.
    the more you know

    https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Eloff at Feb 14, 2015 at 10:07 pm
    That's a great read, thanks for sharing. I'd like to quote:

    "The correct way to express such pattern is to use atomic operations."

    Which is what I mentioned here as well. Otherwise optimizing compilers may
    break your code, like in the article. Go has a memory model that
    specifically disallows data races. However, if you use sync/atomic for all
    accesses, then the compiler is not allowed to mess up your code.

    However, these kinds of shameful tricks in the pursuit of performance
    really only muddle the code and make it less maintainable. It should only
    be used when you have no choice. At least Go, unlike some other languages,
    empowers you with that choice.

    However, blanket statements like there are no benign data races are
    provably false. There are, and they have a use, just use them sparingly.
    On Sat, Feb 14, 2015 at 1:22 PM, Martin Schnabel wrote:
    On 02/14/2015 04:31 PM, Daniel Eloff wrote:

    Yes you have, because I just pointed one out in this thread. If you want
    more examples, have a look at the linux kernel or postgresql or the java
    hotspot compiler. Harmless meaning that the system behaves as intended
    with the data race, e.g. it reads stale data but that doesn't matter.
    There are even harmless write data races, e.g. sometimes some kinds of
    performance counters are not synchronized. This means they might lose
    updates during contention, but the system continues to operate fine with
    approximate values. Unless I am mistaken, hotspot does this in deciding
    what function is hot enough to compile.
    the more you know

    https://software.intel.com/en-us/blogs/2013/01/06/benign-
    data-races-what-could-possibly-go-wrong


    --
    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/RZqeI9-bV_Y/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Benjamin Measures at Feb 15, 2015 at 4:00 pm

    On Friday, 13 February 2015 15:25:20 UTC, Daniel Eloff wrote:
    On Thursday, February 12, 2015 at 3:48:39 AM UTC-5, ma...@joh.to wrote:

    You can't look at numOpen without holding db.mu. But the feature itself
    seems useful.
    Sure you can. You're not allowed to just read the value, according to Go's
    memory model, but you can use sync/atomic to get around that and do a
    "racy" read. It's not less correct that the locked approach, since either
    way by the time your code uses the returned value you're not holding any
    mutex and it can be stale.
    I do not think sync/atomic does what you think it does. Using an
    atomic.LoadInt64 without ensuring that /all/ other operations on the int
    are performed by atomic operations does not give you any more protection or
    guarantee than simply reading the int (ie. no guarantees).
    On Saturday, 14 February 2015 22:08:41 UTC, Daniel Eloff wrote:

    However, if you use sync/atomic for all accesses,
    Key is _for_all_accesses_. You can't just do half a job and not expect
    undefined behaviour. In this case, your race could cause it to read a
    partially written quad-word, despite using atomic.LoadInt64.

    then the compiler is not allowed to mess up your code.
    >

    It's not only about the compiler -- processors are within their rights to
    implement out-of-order execution:
    http://preshing.com/20120515/memory-reordering-caught-in-the-act/

    However, blanket statements like there are no benign data races are
    provably false.
    The article
    <https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong>
    opens with:
    [...] so called “benign” data races -- Why does the tool flag them? Are
    they actually harmful? [...]

    On this definition, (ie. an innocuous-looking race that is flagged by the
    tool) you haven't succeeded in providing a false example. Quite the
    opposite.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Feb 16, 2015 at 1:36 am

    On Sunday, February 15, 2015 at 11:00:07 AM UTC-5, Benjamin Measures wrote:
    I do not think sync/atomic does what you think it does. Using an
    atomic.LoadInt64 without ensuring that /all/ other operations on the int
    are performed by atomic operations does not give you any more protection or
    guarantee than simply reading the int (ie. no guarantees).
    Agreed, you must use it for all accesses. Otherwise a sufficiently clever
    Go compiler could figure out that you don't read the value in the same
    goroutine, and optimize away the store to the variable. It would be rare to
    find such a problem with Go, because the optimizer is not nearly that
    aggressive. But it's undefined behavior, it's wrong, as Dmitry shows
    repeatedly in his article. That's why I mentioned you need to use atomic
    for all accesses.

    It's not only about the compiler -- processors are within their rights to
    implement out-of-order execution:
    http://preshing.com/20120515/memory-reordering-caught-in-the-act/
    That's why x86 has a (reasonably) well defined memory model. If you're
    going to be allowing a data race, you'd better know your target platform(s)
    and whether you need memory barriers or not. In this case, x86 is more than
    strict enough. The worst that can happen, even on a very relaxed
    architecture is stale reads. And that won't happen because the mutex around
    the write acts like a full memory barrier.

    The article <
    https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong>
    opens with:
    [...] so called “benign” data races -- Why does the tool flag them? Are
    they actually harmful? [...]

    On this definition, (ie. an innocuous-looking race that is flagged by the
    tool) you haven't succeeded in providing a false example. Quite the
    opposite.
    I just need one example of a harmless data race to disprove a blanket
    statement like that. I have provided one, use atomic for all accesses to
    the counter and it's harmless. If you don't like that example, I mentioned
    where you can find others. This discussion reminds me too much of the
    "there is no good use of the goto statement". Well there are, and you don't
    have to look too far to find one.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Benjamin Measures at Feb 16, 2015 at 11:31 am

    On Monday, 16 February 2015 01:35:59 UTC, Daniel Eloff wrote:
    That's why I mentioned you need to use atomic for all accesses.
    No, you advocated using sync/atomic to read a mutex-protected variable.

    The worst that can happen [...]
    I don't think you've read any of the linked articles. The worst that can
    happen for behaviour defined as undefined is "anything".

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Feb 16, 2015 at 4:40 pm

    On Monday, February 16, 2015 at 6:31:17 AM UTC-5, Benjamin Measures wrote:

    I don't think you've read any of the linked articles. The worst that can
    happen for behaviour defined as undefined is "anything".

    Again, the keyword is _all_, you must use atomic for _all_ accesses. Not
    just on the read. And I'm not advocating it in this case, better to use the
    lock than to introduce more complex code for zero benefit. How many times
    is one going to query that statistic in real code? I just wanted to point
    out that there are alternatives to a lock in this case for educational
    reasons, not advocate actually using them, nor hijack the thread with a
    long discussion with self appointed race police.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 12, '15 at 6:53a
activeFeb 16, '15 at 4:40p
posts17
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase