FAQ
Please correct me if I'm wrong. It seems that there is an indeterminate
limit to the number of concurrent cgo calls to the same c-lib/c-func (or
to any c-func in general).

Could anyone point me to a resource where I can read more about this limit?

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

Search Discussions

  • James Bardin at Jan 14, 2016 at 4:00 pm

    On Thursday, January 14, 2016 at 10:49:19 AM UTC-5, ksug wrote:
    Please correct me if I'm wrong. It seems that there is an indeterminate
    limit to the number of concurrent cgo calls to the same c-lib/c-func (or
    to any c-func in general).

    Could anyone point me to a resource where I can read more about this
    limit?
    There's a max thread count of 10000. Are you seeing an error about thread
    exhaustion?

    --
    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.
  • Kiki Sugiaman at Jan 14, 2016 at 4:28 pm
    I got (intermittently): "[syscall, locked to thread]" from spawning
    N=100 goroutines. The chance is higher with higher N.

    The code is pretty much:

    wg := sync.WaitGroup()
    // spawn N goroutines and in each perform cgo call doing hello world
    wg.Wait()

    Full panic dump below.






    fatal error: unexpected signal during runtime execution
    fatal error: unexpected signal during runtime execution
    [signal 0xb code=0x80 addr=0x0 pc=0x406230]

    runtime stack:
    runtime.throw(0x54f9c0, 0x2a)
          /usr/local/go/src/runtime/panic.go:527 +0x90
    runtime.sigpanic()
          /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a

    goroutine 89 [syscall, locked to thread]:
    runtime.cgocall(0x4061a0, 0xc8200c37a8, 0x0)
          /usr/local/go/src/runtime/cgocall.go:120 +0x11b fp=0xc8200c3788
    sp=0xc8200c3758
    main._Cfunc_testC()
          _/root/proj/gocallnim/_obj/_cgo_gotypes.go:40 +0x31 fp=0xc8200c37a8
    sp=0xc8200c3788
    main.main.func1(0xc82000a310)
          /root/proj/gocallnim/main.go:25 +0x18 fp=0xc8200c37b8 sp=0xc8200c37a8
    runtime.goexit()
          /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc8200c37c0
    sp=0xc8200c37b8
    created by main.main
          /root/proj/gocallnim/main.go:27 +0x165

    goroutine 1 [semacquire]:
    sync.runtime_Semacquire(0xc82000a31c)
          /usr/local/go/src/runtime/sema.go:43 +0x26
    sync.(*WaitGroup).Wait(0xc82000a310)
          /usr/local/go/src/sync/waitgroup.go:126 +0xb4
    main.main()
          /root/proj/gocallnim/main.go:29 +0x18a

    goroutine 17 [syscall, locked to thread]:
    runtime.goexit()
          /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

    goroutine 88 [syscall, locked to thread]:
    main._Cfunc_testC()
          _/root/proj/gocallnim/_obj/_cgo_gotypes.go:40 +0x31
    main.main.func1(0xc82000a310)
          /root/proj/gocallnim/main.go:25 +0x18
    created by main.main
          /root/proj/gocallnim/main.go:27 +0x165
    [signal 0xb code=0x80 addr=0x0 pc=0x4061cd]

    runtime stack:
    runtime.throw(0x54f9c0, 0x2a)
          /usr/local/go/src/runtime/panic.go:527 +0x90
    runtime.sigpanic()
          /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a

    --
    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.
  • Chris Kastorff at Jan 14, 2016 at 4:47 pm
    IIRC, this isn't doable in general because one cgo call could block waiting
    on another; same problem as with syscalls. For example, consider a running
    wait() syscall on an external process, and a kill() syscall that wants to
    start so it can stop waiting; there's a deadlock if the kill() gets stuck
    on a concurrency limit. Therefore, if there were a generic limit you could
    set, it'd lead to subtle deadlocks.

    The solution to this is to do your concurrency limiting yourself in Go
    code, in a way that's safe from deadlocks (sometimes easy, sometimes not
    depending on the C API requirements.) One way to implement the limiting
    this is by making a buffered channel of struct{}s on initialization, sized
    with the concurrency you want, then write a struct{} to the channel before
    calling cgo and read one back when it has returned. Of course, that's only
    if you have the easy case of "no call blocks for another call" (like the
    wait/kill example I gave.)
    On Thu, Jan 14, 2016 at 8:27 AM, Kiki Sugiaman wrote:

    I got (intermittently): "[syscall, locked to thread]" from spawning N=100
    goroutines. The chance is higher with higher N.

    The code is pretty much:

    wg := sync.WaitGroup()
    // spawn N goroutines and in each perform cgo call doing hello world
    wg.Wait()

    Full panic dump below.






    fatal error: unexpected signal during runtime execution
    fatal error: unexpected signal during runtime execution
    [signal 0xb code=0x80 addr=0x0 pc=0x406230]

    runtime stack:
    runtime.throw(0x54f9c0, 0x2a)
    /usr/local/go/src/runtime/panic.go:527 +0x90
    runtime.sigpanic()
    /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a

    goroutine 89 [syscall, locked to thread]:
    runtime.cgocall(0x4061a0, 0xc8200c37a8, 0x0)
    /usr/local/go/src/runtime/cgocall.go:120 +0x11b fp=0xc8200c3788
    sp=0xc8200c3758
    main._Cfunc_testC()
    _/root/proj/gocallnim/_obj/_cgo_gotypes.go:40 +0x31 fp=0xc8200c37a8
    sp=0xc8200c3788
    main.main.func1(0xc82000a310)
    /root/proj/gocallnim/main.go:25 +0x18 fp=0xc8200c37b8 sp=0xc8200c37a8
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc8200c37c0
    sp=0xc8200c37b8
    created by main.main
    /root/proj/gocallnim/main.go:27 +0x165

    goroutine 1 [semacquire]:
    sync.runtime_Semacquire(0xc82000a31c)
    /usr/local/go/src/runtime/sema.go:43 +0x26
    sync.(*WaitGroup).Wait(0xc82000a310)
    /usr/local/go/src/sync/waitgroup.go:126 +0xb4
    main.main()
    /root/proj/gocallnim/main.go:29 +0x18a

    goroutine 17 [syscall, locked to thread]:
    runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

    goroutine 88 [syscall, locked to thread]:
    main._Cfunc_testC()
    _/root/proj/gocallnim/_obj/_cgo_gotypes.go:40 +0x31
    main.main.func1(0xc82000a310)
    /root/proj/gocallnim/main.go:25 +0x18
    created by main.main
    /root/proj/gocallnim/main.go:27 +0x165
    [signal 0xb code=0x80 addr=0x0 pc=0x4061cd]

    runtime stack:
    runtime.throw(0x54f9c0, 0x2a)
    /usr/local/go/src/runtime/panic.go:527 +0x90
    runtime.sigpanic()
    /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a


    --
    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.
  • Ian Lance Taylor at Jan 14, 2016 at 5:09 pm

    On Thu, Jan 14, 2016 at 8:27 AM, Kiki Sugiaman wrote:
    I got (intermittently): "[syscall, locked to thread]" from spawning N=100
    goroutines. The chance is higher with higher N.
    [syscall, locked to thread] is normal. It means that the thread is
    executing a system call or is calling a cgo function.
    The code is pretty much:

    wg := sync.WaitGroup()
    // spawn N goroutines and in each perform cgo call doing hello world
    wg.Wait()

    Full panic dump below.






    fatal error: unexpected signal during runtime execution
    fatal error: unexpected signal during runtime execution
    [signal 0xb code=0x80 addr=0x0 pc=0x406230]
    This is your error. You are getting a SIGSEGV at PC address 0x406230.
    It's a dereference of a nil pointer. The error is telling you that
    the signal is occurring while running C code or while running inside
    the Go runtime itself. Look at the PC address to find out where the
    error is occurring.

    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.
  • Manlio Perillo at Jan 14, 2016 at 9:19 pm
    Il giorno giovedì 14 gennaio 2016 18:09:41 UTC+1, Ian Lance Taylor ha
    scritto:
    On Thu, Jan 14, 2016 at 8:27 AM, Kiki Sugiaman <ksug...@gmail.com
    <javascript:>> wrote:
    I got (intermittently): "[syscall, locked to thread]" from spawning N=100
    goroutines. The chance is higher with higher N.
    [...]

    fatal error: unexpected signal during runtime execution
    fatal error: unexpected signal during runtime execution
    [signal 0xb code=0x80 addr=0x0 pc=0x406230]
    This is your error. You are getting a SIGSEGV at PC address 0x406230.
    It's a dereference of a nil pointer.
    What is the reason why the runtime does not make this error report a bit
    more user friendly?
    As an example by printing the signal name, instead of the signal code, and
    by reporting the source code line for the PC.


    Thanks Manlio

    --
    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.
  • Ian Lance Taylor at Jan 14, 2016 at 10:48 pm

    On Thu, Jan 14, 2016 at 1:19 PM, Manlio Perillo wrote:
    Il giorno giovedì 14 gennaio 2016 18:09:41 UTC+1, Ian Lance Taylor ha
    scritto:
    On Thu, Jan 14, 2016 at 8:27 AM, Kiki Sugiaman wrote:
    I got (intermittently): "[syscall, locked to thread]" from spawning
    N=100
    goroutines. The chance is higher with higher N.

    [...]

    fatal error: unexpected signal during runtime execution
    fatal error: unexpected signal during runtime execution
    [signal 0xb code=0x80 addr=0x0 pc=0x406230]
    This is your error. You are getting a SIGSEGV at PC address 0x406230.
    It's a dereference of a nil pointer.

    What is the reason why the runtime does not make this error report a bit
    more user friendly?
    As an example by printing the signal name, instead of the signal code, and
    by reporting the source code line for the PC.
    It could print the signal name. Please file an issue for that.

    There is no easy way to print the source code line. This PC is in C
    code, not Go code. The Go runtime doesn't have a good way to
    translate the C debug info (if there is any) into file/line
    information while it is in the process of crashing.

    In general, we try hard for good error reporting for Go code. What we
    are able to do for C code is much more limited.

    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.
  • Manlio Perillo at Jan 15, 2016 at 11:04 am
    Il giorno giovedì 14 gennaio 2016 23:48:17 UTC+1, Ian Lance Taylor ha
    scritto:
    [...]
    fatal error: unexpected signal during runtime execution
    fatal error: unexpected signal during runtime execution
    [signal 0xb code=0x80 addr=0x0 pc=0x406230]
    This is your error. You are getting a SIGSEGV at PC address 0x406230.
    It's a dereference of a nil pointer.

    What is the reason why the runtime does not make this error report a bit
    more user friendly?
    As an example by printing the signal name, instead of the signal code, and
    by reporting the source code line for the PC.
    It could print the signal name. Please file an issue for that.
    https://github.com/golang/go/issues/13969

    Thanks.


    Manlio

    --
    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.
  • Kiki Sugiaman at Jan 15, 2016 at 5:10 am
    The C code I was calling into was actually 2 lines of nim code (func
    definition + print hello, which compiles to C), so there's nothing much
    to debug there. However, since both nim and go are memory managed,
    either may have stepped into another's toe.

    I may bring this to the nim folks, let's see.

    Thank you for the inputs.

    --
    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
postedJan 14, '16 at 3:49p
activeJan 15, '16 at 11:04a
posts9
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase