FAQ
Hi! Go encourages writing structs to be of small scope, with just the
right, needed functionality, and without bloat unneeded by most. The idea
is one can always write their own implementation; one can simply take the
struct's source, define a new type with the changes needed for the new use
case, and go on.

As far as I understand
<https://github.com/jbenet/go-fd-mutex/blob/master/README.md#go-fd-mutex>,
`runtime_*` functions are implemented internally in the go src and replaced
by `src/cmd/dist/goc2c.c`, which only runs for go code. This makes it
impossible for anyone to use `runtime_*` functions, which I understand is a
safety rail. (yay, <3 not shooting myself in the face).

Using these functions for things like net.fdmutex
(http://golang.org/src/pkg/net/fd_mutex.go#L183) or sync.Pool
(http://golang.org/src/pkg/sync/pool.go#L220) makes it literally impossible
for us to write packages for others which borrow functionality from core
golang structs and have similar levels of performance.

I would suggest making most of the `runtime_*` functions accessible. i dont
think incorrectly using `runtime_Semacquire` is going to rip a hole in the
fabric of spacetime, and while people can most likely break things if they
register the wrong function in `runtime_registerPoolCleanup`, it's likely
to be a similar outcome to causing a panic.

--
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

  • Ian Lance Taylor at Dec 6, 2014 at 5:31 am

    On Fri, Dec 5, 2014 at 3:37 PM, Juan Batiz-Benet wrote:
    Hi! Go encourages writing structs to be of small scope, with just the right,
    needed functionality, and without bloat unneeded by most. The idea is one
    can always write their own implementation; one can simply take the struct's
    source, define a new type with the changes needed for the new use case, and
    go on.

    As far as I understand, `runtime_*` functions are implemented internally in
    the go src and replaced by `src/cmd/dist/goc2c.c`, which only runs for go
    code. This makes it impossible for anyone to use `runtime_*` functions,
    which I understand is a safety rail. (yay, <3 not shooting myself in the
    face).

    Using these functions for things like net.fdmutex
    (http://golang.org/src/pkg/net/fd_mutex.go#L183) or sync.Pool
    (http://golang.org/src/pkg/sync/pool.go#L220) makes it literally impossible
    for us to write packages for others which borrow functionality from core
    golang structs and have similar levels of performance.

    I would suggest making most of the `runtime_*` functions accessible. i dont
    think incorrectly using `runtime_Semacquire` is going to rip a hole in the
    fabric of spacetime, and while people can most likely break things if they
    register the wrong function in `runtime_registerPoolCleanup`, it's likely to
    be a similar outcome to causing a panic.
    We're not going to do that, because it would mean that we could not
    change the behaviour of the runtime functions, because doing so would
    break people's programs. We need to keep API surfaces small and
    maintainable.

    Ian

    --
    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.
  • Matt Sherman at Dec 7, 2014 at 1:06 am
    Assume this is likely to change in 1.5, with the rewrite of runtime to Go?
    I ran into this just today, trying to make a strongly-typed version of
    sync.Pool.
    On Saturday, December 6, 2014 12:31:28 AM UTC-5, Ian Lance Taylor wrote:

    On Fri, Dec 5, 2014 at 3:37 PM, Juan Batiz-Benet <ju...@benet.ai
    <javascript:>> wrote:
    Hi! Go encourages writing structs to be of small scope, with just the right,
    needed functionality, and without bloat unneeded by most. The idea is one
    can always write their own implementation; one can simply take the struct's
    source, define a new type with the changes needed for the new use case, and
    go on.

    As far as I understand, `runtime_*` functions are implemented internally in
    the go src and replaced by `src/cmd/dist/goc2c.c`, which only runs for go
    code. This makes it impossible for anyone to use `runtime_*` functions,
    which I understand is a safety rail. (yay, <3 not shooting myself in the
    face).

    Using these functions for things like net.fdmutex
    (http://golang.org/src/pkg/net/fd_mutex.go#L183) or sync.Pool
    (http://golang.org/src/pkg/sync/pool.go#L220) makes it literally
    impossible
    for us to write packages for others which borrow functionality from core
    golang structs and have similar levels of performance.

    I would suggest making most of the `runtime_*` functions accessible. i dont
    think incorrectly using `runtime_Semacquire` is going to rip a hole in the
    fabric of spacetime, and while people can most likely break things if they
    register the wrong function in `runtime_registerPoolCleanup`, it's likely to
    be a similar outcome to causing a panic.
    We're not going to do that, because it would mean that we could not
    change the behaviour of the runtime functions, because doing so would
    break people's programs. We need to keep API surfaces small and
    maintainable.

    Ian
    --
    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.
  • Rob Pike at Dec 7, 2014 at 1:13 am
    It is very unlikely to change.

    -rob

    On Sun, Dec 7, 2014 at 10:06 AM, Matt Sherman wrote:

    Assume this is likely to change in 1.5, with the rewrite of runtime to Go?
    I ran into this just today, trying to make a strongly-typed version of
    sync.Pool.
    On Saturday, December 6, 2014 12:31:28 AM UTC-5, Ian Lance Taylor wrote:
    On Fri, Dec 5, 2014 at 3:37 PM, Juan Batiz-Benet wrote:

    Hi! Go encourages writing structs to be of small scope, with just the right,
    needed functionality, and without bloat unneeded by most. The idea is one
    can always write their own implementation; one can simply take the struct's
    source, define a new type with the changes needed for the new use case, and
    go on.

    As far as I understand, `runtime_*` functions are implemented
    internally in
    the go src and replaced by `src/cmd/dist/goc2c.c`, which only runs for go
    code. This makes it impossible for anyone to use `runtime_*` functions,
    which I understand is a safety rail. (yay, <3 not shooting myself in the
    face).

    Using these functions for things like net.fdmutex
    (http://golang.org/src/pkg/net/fd_mutex.go#L183) or sync.Pool
    (http://golang.org/src/pkg/sync/pool.go#L220) makes it literally
    impossible
    for us to write packages for others which borrow functionality from core
    golang structs and have similar levels of performance.

    I would suggest making most of the `runtime_*` functions accessible. i dont
    think incorrectly using `runtime_Semacquire` is going to rip a hole in the
    fabric of spacetime, and while people can most likely break things if they
    register the wrong function in `runtime_registerPoolCleanup`, it's likely to
    be a similar outcome to causing a panic.
    We're not going to do that, because it would mean that we could not
    change the behaviour of the runtime functions, because doing so would
    break people's programs. We need to keep API surfaces small and
    maintainable.

    Ian
    --
    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.
    --
    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.
  • Matt Sherman at Dec 7, 2014 at 4:36 am
    Thank you for the reply. Would love to see a writeup of this pattern.

    With the caveat that I don't know what I am talking about -- could the asm
    be implemented in the compiler instead of as /pkg source? I'd love to be
    able to reuse sync code outside of stdlib.
    On Saturday, December 6, 2014 8:14:14 PM UTC-5, Rob 'Commander' Pike wrote:

    It is very unlikely to change.

    -rob


    On Sun, Dec 7, 2014 at 10:06 AM, Matt Sherman <mwsh...@gmail.com
    <javascript:>> wrote:
    Assume this is likely to change in 1.5, with the rewrite of runtime to
    Go? I ran into this just today, trying to make a strongly-typed version of
    sync.Pool.
    On Saturday, December 6, 2014 12:31:28 AM UTC-5, Ian Lance Taylor wrote:

    On Fri, Dec 5, 2014 at 3:37 PM, Juan Batiz-Benet <ju...@benet.ai>
    wrote:
    Hi! Go encourages writing structs to be of small scope, with just the right,
    needed functionality, and without bloat unneeded by most. The idea is one
    can always write their own implementation; one can simply take the struct's
    source, define a new type with the changes needed for the new use case, and
    go on.

    As far as I understand, `runtime_*` functions are implemented
    internally in
    the go src and replaced by `src/cmd/dist/goc2c.c`, which only runs for go
    code. This makes it impossible for anyone to use `runtime_*`
    functions,
    which I understand is a safety rail. (yay, <3 not shooting myself in the
    face).

    Using these functions for things like net.fdmutex
    (http://golang.org/src/pkg/net/fd_mutex.go#L183) or sync.Pool
    (http://golang.org/src/pkg/sync/pool.go#L220) makes it literally
    impossible
    for us to write packages for others which borrow functionality from core
    golang structs and have similar levels of performance.

    I would suggest making most of the `runtime_*` functions accessible. i dont
    think incorrectly using `runtime_Semacquire` is going to rip a hole in the
    fabric of spacetime, and while people can most likely break things if they
    register the wrong function in `runtime_registerPoolCleanup`, it's likely to
    be a similar outcome to causing a panic.
    We're not going to do that, because it would mean that we could not
    change the behaviour of the runtime functions, because doing so would
    break people's programs. We need to keep API surfaces small and
    maintainable.

    Ian
    --
    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...@googlegroups.com <javascript:>.
    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.
  • Lars Seipel at Dec 7, 2014 at 5:53 am

    On Sat, Dec 06, 2014 at 08:36:51PM -0800, Matt Sherman wrote:
    With the caveat that I don't know what I am talking about -- could the asm
    be implemented in the compiler instead of as /pkg source? I'd love to be
    able to reuse sync code outside of stdlib.
    Like Ian said, use of runtime support code outside of the runtime and
    stdlib is exactly what people are trying to prevent. This code can (and
    does!) change all the time without prior notice. You can't do this
    anymore if there are users outside of the source tree.

    Writing some warning next to it just doesn't work, as history has shown.
    All it takes is one popular out-of-tree user and it would prevent users
    from updating their Go installation.

    If it turns out that some functionality is more generally useful, what's
    done is to build a supportable API for it and export *that* to user
    code. This is what happened with sync.Pool, by the way.

    --
    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
postedDec 5, '14 at 11:37p
activeDec 7, '14 at 5:53a
posts6
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase