On Mon, Nov 7, 2016 at 12:44 PM, Seb Binet <seb.bi...@gmail.com> wrote:
> > > On Sun, Nov 6, 2016 at 8:21 PM, Mateusz Dymiński <dymin...@gmail.com> > wrote: > >> I haven't played with the plugin feature yet, but some things stand out >>> to me about your code and I wonder if it is correct or not. >>> Is there a difference in using go build vs go run, in the same way as >>> you can get bad behaviour using go run with more complex apps? >> >> Have you tried moving those plugins to subdirs so that you don't have 3 >>> mains in one location when running go build? >> >> >> I tried to move the implementation to separate directories - no success. >> Same thing with 'go run' and 'go build' and then run the binary. Changes >> are already in the repo: https://github.com/mateuszdyminski/go-plugin >> >> Is it necessary to import the processor and printer libs just so that you >>> can make specific interface values? If interfaces are satisfied implicitly, >>> then why can't you just make an instance of your local concrete type >>> without importing the interfaces? "Impl" should be able to satisfy a >>> printer or processor without you explicitly importing and declaring it as >>> one. Unless something is special about plugins? >> >> >> The example in the repository is the simplest way to reproduce the bug >> which I probably found in the plugin feature. >> >> The truth is that I would like to write the MapReduce implementation >> where there is master process which coordinates the worker processes and >> similar to the Hadoop user can submit the job which should be calculated by >> the MapReduce. User has to write struct which should implement the >> MapReduce interface - it tells to the workers how the 'map' and 'reduce' >> phase should be calculated. In the same time this framework should be able >> to calculate multiple jobs with multiple implementations of MapReduce and >> that's why I need to load the different plugins multiple times. I guess >> It's great use case for the new plugin feature. >> > > it is probably a bug in stdlib's "plugin". > > but, if you modify your build's instructions from: > cd printer-impl && go build -buildmode=plugin printer.go > cd processor-impl && go build -buildmode=plugin processor.go > go run main.go > > to: > cd printer-impl && go build -buildmode=plugin . > cd processor-impl && go build -buildmode=plugin . > go run main.go > > (after having modified "main.go" to load "printer-impl/printer-impl.so" > and "processor/processor-impl.so") > > everything works. > > (modifying plugin compilation to "go build -buildmode=plugin -o printer.so > ." fails later with: > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 > pc=0x7f23278e9cc0] > > goroutine 1 [running]: > panic(0x498720, 0x6db110) > /home/binet/dev/go/root/go/src/runtime/panic.go:531 +0x1cf > os.(*File).write(0x0, 0xc42000c260, 0x13, 0x20, 0x20, 0xc42007c000, > 0x7f2327914717) > /home/binet/dev/go/root/go/src/os/file_unix.go:181 +0x50 > os.(*File).Write(0x0, 0xc42000c260, 0x13, 0x20, 0x1, 0x1, 0x0) > /home/binet/dev/go/root/go/src/os/file.go:142 +0x7e > fmt.Fprintf(0x7f2327ba30e0, 0x0, 0x7f2327914707, 0x11, 0xc42004be68, 0x1, > 0x1, 0xc420010180, 0xc42004be58, 0xc420010180) > /home/binet/dev/go/root/go/src/fmt/print.go:182 +0xab > fmt.Printf(0x7f2327914707, 0x11, 0xc42004be68, 0x1, 0x1, 0xc42001a120, > 0xc42001a120, 0x0) > /home/binet/dev/go/root/go/src/fmt/print.go:190 +0x77 > github.com/mateuszdyminski/go-plugin/printer-impl. > PrinterImpl.Print(0x4a53b0, 0x4) > /home/binet/dev/go/root/path/src/github.com/mateuszdyminski/go-plugin/ > printer-impl/printer.go:16 +0xac > github.com/mateuszdyminski/go-plugin/printer-impl.(*PrinterImpl).Print( > 0x7f2327bbff20, 0x4a53b0, 0x4) > <autogenerated>:1 +0x5b > main.main() > /home/binet/dev/go/root/path/src/github.com/mateuszdyminski/go-plugin/ > main.go:26 +0x122 > > so that's probably another plugin bug.) > ah. it seems that for the last issue, one "just" has to import "os" in go-plugin/main.go. and it magically fixes everything as a weird side-effect. -s -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
