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.) please report these issues on the bug tracker. thanks, -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.
