FAQ
I just come across this (http://code.google.com/p/seccompsandbox/) project
today,
i wonder if the we can make use of this sandbox to make a playground like
service.

--

Search Discussions

  • André Moraes at Nov 24, 2012 at 5:07 pm
    AFAIK, The Go-app-engine SDK simulate the same restrictions applied to
    the deployed code (on google servers)

    Their jail should be at least an inspiration for yours.

    --
    André Moraes
    http://amoraes.info

    --
  • Minux at Nov 24, 2012 at 5:11 pm

    On Sun, Nov 25, 2012 at 12:59 AM, André Moraes wrote:

    AFAIK, The Go-app-engine SDK simulate the same restrictions applied to
    the deployed code (on google servers)
    does it?
    i think you can create files if running locally with go app engine sdk, but
    you can't if deployed.

    --
  • John Nagle at Mar 31, 2013 at 3:51 am

    On 11/24/2012 8:53 AM, minux wrote:
    I just come across this (http://code.google.com/p/seccompsandbox/) project
    today,
    i wonder if the we can make use of this sandbox to make a playground like
    service.
    Of course, you have to prohibit concurrency. Go is only memory safe
    in single-thread mode.

    John Nagle



    --
    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/groups/opt_out.
  • Jan Mercl at Mar 31, 2013 at 3:56 am
    You are permanently (intentionally?) ignoring the difference between a
    language and it's implementation. Please.

    -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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Mar 31, 2013 at 5:15 am

    On 3/30/2013 8:56 PM, Jan Mercl wrote:
    You are permanently (intentionally?) ignoring the difference between a
    language and it's implementation. Please.
    It's a designed-in property of the language that it's a hard language
    to make concurrency safe. Denying this will not help.

    Python has the same problem, and deals with it using the infamous
    Global Interpreter Lock. Go in single-thread mode is roughly equivalent
    to Python in terms of being unable to utilize multiple CPUs.

    John Nagle


    --
    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/groups/opt_out.
  • David Symonds at Mar 31, 2013 at 5:21 am

    On Sun, Mar 31, 2013 at 4:14 PM, John Nagle wrote:
    On 3/30/2013 8:56 PM, Jan Mercl wrote:
    You are permanently (intentionally?) ignoring the difference between a
    language and it's implementation. Please.
    It's a designed-in property of the language that it's a hard language
    to make concurrency safe. Denying this will not help.
    Actually it's not all that conceptually hard. You just have to make
    all the multi-word builtin types concurrent safe (interfaces, slices,
    funcs, maps, ...), which could be done relatively simplistically if
    you don't mind mucking around in the compiler and runtime.

    --
    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/groups/opt_out.
  • Ian Lance Taylor at Mar 31, 2013 at 5:21 am

    On Sat, Mar 30, 2013 at 10:14 PM, John Nagle wrote:
    On 3/30/2013 8:56 PM, Jan Mercl wrote:
    You are permanently (intentionally?) ignoring the difference between a
    language and it's implementation. Please.
    It's a designed-in property of the language that it's a hard language
    to make concurrency safe. Denying this will not help.
    No. Go is a hard language to make parallel-safe. But that is not the
    issue that matters here. It is possible to make Go programs memory
    safe, in that they are unable to create an invalid pointer without
    using the unsafe package. With respect to the playground, it does not
    matter whether a Go program can have race conditions. It only matters
    whether it can construct an invalid pointer.

    Python has the same problem, and deals with it using the infamous
    Global Interpreter Lock. Go in single-thread mode is roughly equivalent
    to Python in terms of being unable to utilize multiple CPUs.
    That is false for several reasons, as I'm sure you'll see if you think
    about it.

    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/groups/opt_out.
  • David Anderson at Mar 31, 2013 at 5:42 am

    On Sat, Mar 30, 2013 at 10:21 PM, Ian Lance Taylor wrote:
    On Sat, Mar 30, 2013 at 10:14 PM, John Nagle wrote:
    On 3/30/2013 8:56 PM, Jan Mercl wrote:
    You are permanently (intentionally?) ignoring the difference between a
    language and it's implementation. Please.
    It's a designed-in property of the language that it's a hard language
    to make concurrency safe. Denying this will not help.
    No. Go is a hard language to make parallel-safe. But that is not the
    issue that matters here. It is possible to make Go programs memory
    safe, in that they are unable to create an invalid pointer without
    using the unsafe package. With respect to the playground, it does not
    matter whether a Go program can have race conditions. It only matters
    whether it can construct an invalid pointer.
    But, to clarify: the current gc and gccgo implementations *do* allow
    construction of invalid pointers via specific data races, correct? Or did I
    miss a runtime change that altered the semantics?

    Of course, that doesn't mean that it's hard to make that change. I'm just
    making sure that I know the current state of the implementations.

    - Dave

    Python has the same problem, and deals with it using the infamous
    Global Interpreter Lock. Go in single-thread mode is roughly equivalent
    to Python in terms of being unable to utilize multiple CPUs.
    That is false for several reasons, as I'm sure you'll see if you think
    about it.

    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/groups/opt_out.

    --
    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/groups/opt_out.
  • John Nagle at Mar 31, 2013 at 5:49 am

    On 3/30/2013 10:41 PM, David Anderson wrote:
    On Sat, Mar 30, 2013 at 10:21 PM, Ian Lance Taylor wrote:
    On Sat, Mar 30, 2013 at 10:14 PM, John Nagle wrote:
    On 3/30/2013 8:56 PM, Jan Mercl wrote:
    You are permanently (intentionally?) ignoring the difference between a
    language and it's implementation. Please.
    It's a designed-in property of the language that it's a hard language
    to make concurrency safe. Denying this will not help.
    No. Go is a hard language to make parallel-safe. But that is not the
    issue that matters here. It is possible to make Go programs memory
    safe, in that they are unable to create an invalid pointer without
    using the unsafe package. With respect to the playground, it does not
    matter whether a Go program can have race conditions. It only matters
    whether it can construct an invalid pointer.
    But, to clarify: the current gc and gccgo implementations *do* allow
    construction of invalid pointers via specific data races, correct? Or did I
    miss a runtime change that altered the semantics?

    Of course, that doesn't mean that it's hard to make that change. I'm just
    making sure that I know the current state of the implementations.

    - Dave
    Google's AppEngine is still locked down to single-thread mode for
    sandboxing purposes. See

    https://developers.google.com/appengine/docs/go/overview

    See "http://research.swtch.com/gorace" for how to create an invalid
    pointer exploit using a multi-threaded Go program. We've been through
    this before. There's a lot of denial about Go's concurrency safety.

    John Nagle

    --
    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/groups/opt_out.
  • David Symonds at Mar 31, 2013 at 5:58 am

    On Sun, Mar 31, 2013 at 4:48 PM, John Nagle wrote:

    Google's AppEngine is still locked down to single-thread mode for
    sandboxing purposes. See

    https://developers.google.com/appengine/docs/go/overview
    Yes, but that's mainly due to no-one having changed the
    *implementation* details of the multi-word builtin types. That doesn't
    imply anything about the language itself.
    See "http://research.swtch.com/gorace" for how to create an invalid
    pointer exploit using a multi-threaded Go program. We've been through
    this before. There's a lot of denial about Go's concurrency safety.
    I can't tell whether you are intentionally obfuscating, missing the
    point, or just trolling. That page says "This post describes the races
    and how to rearrange the data structures involved to avoid them.",
    and, with the proviso that the unsafe package is, well, unsafe, it
    explains how the current implementation can be made memory safe.
    No-one denies that the current implementation has
    not-safe-for-concurrent-use builtin types, but that's an artifact of
    the implementation.

    --
    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/groups/opt_out.
  • John Nagle at Mar 31, 2013 at 6:01 pm

    On 3/30/2013 10:58 PM, David Symonds wrote:
    On Sun, Mar 31, 2013 at 4:48 PM, John Nagle wrote:

    Google's AppEngine is still locked down to single-thread mode for
    sandboxing purposes. See

    https://developers.google.com/appengine/docs/go/overview
    Yes, but that's mainly due to no-one having changed the
    *implementation* details of the multi-word builtin types. That doesn't
    imply anything about the language itself.
    See "http://research.swtch.com/gorace" for how to create an invalid
    pointer exploit using a multi-threaded Go program. We've been through
    this before. There's a lot of denial about Go's concurrency safety.
    No-one denies that the current implementation has
    not-safe-for-concurrent-use builtin types, but that's an artifact of
    the implementation.
    By design, Go maps are not thread-safe. Locking overhead
    was considered to be too high. It might be possible to implement
    maps using atomic operations such as swap and compare-and-swap.
    Resizing is a headache, but if the entire map was redirected
    as Russ Cox proposes for slices, then resizing by building
    a new (bigger) map and replacing the old one in its entirety works.
    This is memory-safe and lock free, but not concurrency-correct.
    Two threads could be updating the same map during a resize, and
    the updates from only one of them will be kept. Still, it's
    far better than the current "crash on concurrent update" implementation.

    Russ Cox's proposed fix for slices costs an extra redirection
    on each slice access. This might be feasible for number-crunching
    work if Go supported multidimensional slices. (Then you redirect
    once per array, not once per row.) Since multidimensional slices
    would also reduce subscript checking overhead (all rows are the
    same length), it would make sense to put that in at the same time
    slices were made thread-safe. This is in an area where performance
    matters - inner loops of array operations. So it's worth getting right.

    John Nagle




    --
    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/groups/opt_out.
  • Jan Mercl at Mar 31, 2013 at 6:15 pm

    On Sun, Mar 31, 2013 at 8:01 PM, John Nagle wrote:

    By design, Go maps are not thread-safe.
    You have presented a false fact about Go _memory safety_.
    Go is only memory safe in single-thread mode.
    You've done that for Nth time already and you've been always proven
    incorrect on this (to say it *very* politely).

    A sudden change of the topic from "memory safe" to "thread safe"
    doesn't change anything of the above.

    -j

    PS:Many things in Go are not safe for concurrent access. Actually
    nothing except when explicitly stated otherwise. So what's the news
    actually?

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 24, '12 at 4:53p
activeMar 31, '13 at 6:15p
posts13
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase