Shared Library?

[JackDunaway]

With new development slated for Go 1.5 (link: http:https://talks.golang.org/2015/state-of-go-may.slide#13) and the option -buildmode=c-shared, I'm wondering how feasible it is to build mangos as a self-contained shared library.

To begin a technical investigation, with Go 1.5 still not released, even as a pre-release package, it appears one would need to compile Go 1.5 against 1.4 (link to bootstrapping plan: http:https://golang.org/s/go15bootstrap). I've casually started working on this as spare time permits, but wanted to go ahead and kick off a conversation here.

Thoughts?

[gdamore]

This looks pretty cool. I'm not super anxious to do this work now, given that go 1.5 is several months from from general release. But once 1.5 releases, it looks very interesting. The plugin model may work very well for adding support for nicely extending transports too!

[JackDunaway]

OK, status update:

Built 1.5 bootstrapped with 1.4 (from this commit: golang/go@f04e7bb)

Running go test -bench=. github.com/gdamore/mangos/test yields the following error:

Jack-MacBookAir13-Mid2013:~ jack$ go test -bench=. github.com/gdamore/mangos/test
PASS
BenchmarkLatencyInp   200000         10244 ns/op
BenchmarkLatencyIPC    30000         37257 ns/op
BenchmarkLatencyTCP    20000         80782 ns/op
BenchmarkLatencyTLS    20000         90862 ns/op
BenchmarkLatencyWS     20000         89721 ns/op
BenchmarkLatencyWSS    10000        128444 ns/op
BenchmarkTPut4kInp    200000          5647 ns/op     725.28 MB/s
BenchmarkTPut4kIPC    200000         11354 ns/op     360.73 MB/s
BenchmarkTPut4kTCP    100000         19116 ns/op     214.26 MB/s
BenchmarkTPut4kTLS    100000         15789 ns/op     259.41 MB/s
BenchmarkTPut4kWS   SIGQUIT: quit
PC=0x5a73b m=0

goroutine 0 [idle]:
runtime.mach_semaphore_wait(0xd03, 0xc20000000e, 0xc2084d83c0, 0xc2084d8000, 0x3275, 0x600240, 0x4dea0, 0xffffffffffffffff, 0x32b5, 0x7fff5fbff894, ...)
    /Users/jack/repo/wirebird-go/src/runtime/sys_darwin_amd64.s:407 +0xb
runtime.semasleep1(0xffffffffffffffff, 0x32b5)
    /Users/jack/repo/wirebird-go/src/runtime/os1_darwin.go:380 +0xee
runtime.semasleep.func1()
    /Users/jack/repo/wirebird-go/src/runtime/os1_darwin.go:396 +0x30
runtime.systemstack(0x7fff5fbff898)
    /Users/jack/repo/wirebird-go/src/runtime/asm_amd64.s:278 +0xb1
runtime.semasleep(0xffffffffffffffff, 0x0)
    /Users/jack/repo/wirebird-go/src/runtime/os1_darwin.go:397 +0x36
runtime.notesleep(0x6008a8)
    /Users/jack/repo/wirebird-go/src/runtime/lock_sema.go:169 +0x112
runtime.stopm()
    /Users/jack/repo/wirebird-go/src/runtime/proc1.go:1110 +0x127
runtime.exitsyscall0(0xc2082db540)
    /Users/jack/repo/wirebird-go/src/runtime/proc1.go:2106 +0x17e
runtime.mcall(0x7fff5fbff960)
    /Users/jack/repo/wirebird-go/src/runtime/asm_amd64.s:204 +0x5e

goroutine 1 [chan receive, 9 minutes]:
testing.(*B).run(0xc208094900, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/jack/repo/wirebird-go/src/testing/benchmark.go:180 +0x7e
testing.RunBenchmarks(0x4bb478, 0x5fb760, 0x12, 0x12)
    /Users/jack/repo/wirebird-go/src/testing/benchmark.go:332 +0x762
testing.(*M).Run(0xc208039f38, 0x0)
    /Users/jack/repo/wirebird-go/src/testing/testing.go:501 +0x1bb
main.main()
    github.com/gdamore/mangos/test/_test/_testmain.go:202 +0x119

goroutine 17 [syscall, 11 minutes, locked to thread]:
runtime.goexit()
    /Users/jack/repo/wirebird-go/src/runtime/asm_amd64.s:1670 +0x1

goroutine 1676 [chan receive, 9 minutes]:
github.com/gdamore/mangos/test.benchmarkPair(0xc208094900, 0x46a7d0, 0x1e, 0x1000)
    /Users/jack/go/src/github.com/gdamore/mangos/test/benchmark_test.go:164 +0x449
github.com/gdamore/mangos/test.BenchmarkTPut4kWS(0xc208094900)
    /Users/jack/go/src/github.com/gdamore/mangos/test/benchmark_test.go:227 +0x49
testing.(*B).runN(0xc208094900, 0x64)
    /Users/jack/repo/wirebird-go/src/testing/benchmark.go:124 +0x9d
testing.(*B).launch(0xc208094900)
    /Users/jack/repo/wirebird-go/src/testing/benchmark.go:216 +0x134
created by testing.(*B).run
    /Users/jack/repo/wirebird-go/src/testing/benchmark.go:179 +0x57

rax    0xe
rbx    0xd03
rcx    0x7fff5fbff820
rdx    0x7fff5fbff898
rdi    0xd03
rsi    0x600240
rbp    0x6007a0
rsp    0x7fff5fbff820
r8     0x0
r9     0x0
r10    0x0
r11    0x246
r12    0x2
r13    0x4ba987
r14    0x8
r15    0x0
rip    0x5a73b
rflags 0x246
cs     0x7
fs     0x0
gs     0x0
*** Test killed with quit: ran too long (10m0s).
FAIL    github.com/gdamore/mangos/test  671.838s

It's not necessarily worth looking into an error generated by a pre-release compiler, but wanted to report here anyway in case it's useful. As a comparision, the tests and benchmarks work well when compiled with Go 1.4 Release.

[JackDunaway]

Status update:

Not sure what I'm doing yet! But it seems I'll need to create a small wrapper that defines the exports (or something like that...)

Jack-MacBookAir13-Mid2013:~ jack$ go build -buildmode=c-archive github.com/gdamore/mangos
-buildmode=c-archive requires exactly one main package

[JackDunaway]

Status update:

Not sure if c-shared will be cross-platform by Go 1.5 release timeline around August 2015, but it's not right now:

Jack-MacBookAir13-Mid2013:~ jack$ go build -buildmode=c-shared github.com/gdamore/mangos/c
-buildmode=c-shared not supported on darwin/amd64

Currently, only linux and android platforms supported (not Windows and OS X): https://github.com/golang/go/blob/de305a197f5c9ca3bb09da024e06ba7be0c7435d/src/cmd/go/build.go#L326-L341

[JackDunaway]

Windows

Support slated for Go 1.6: golang/go#11058

[JackDunaway]

Support slated for Go 1.6: golang/go#11058

This is now deferred indefinitely from 1.6 to Unplanned: golang/go#11058 (comment)

[gdamore]

I think I'm going to close this issue for now. When it works reasonably reliably well and is supported by Go on the major Go platforms, then we should revisit. I'm also less convinced this offers much benefit except to people wanting to use mangos from non-Go platforms. Given the existence of nanomsg, its unclear that there is much demand for this.

Further, I'd have some pretty serious concerns about supporting this in non-Go runtimes. For an example of the heartache that can occur, see the discussion around fork-safety and nanomsg recently. There is a certain bliss achieved by simply pretending such things don't happen in the real world, and supporting other runtimes / environments would shatter my utopian world view, hurling me from my perfect nirvana. :-)