> > 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. W dniu niedziela, 6 listopada 2016 19:36:26 UTC+1 użytkownik Justin Israel napisał: > > 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? > > 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? > > Justin > > On Mon, 7 Nov 2016, 7:18 AM Mateusz Dymiński <dymi...@gmail.com > <javascript:>> wrote: > >> Does it mean that I can't load the two different plugins ? >> >> I know that I can't load the same plugin twice, but I thought that I can >> load two different plugins. >> >> To be precise I was thinking about the MapReduce implementation where the >> client might build the go program which can be loaded as plugin on the >> workers - similar approach is in Hadoop. My main assumption was that the >> same worker written in go cant load plugins for each MapReduce job. Is it >> possible with current plugin go feature ? >> >> >> W dniu niedziela, 6 listopada 2016 06:57:52 UTC+1 użytkownik Tamás >> Gulácsi napisał: >>> >>> AFAIK it's a design decision that a plugin cannot be loaded twice. >>> Protect it with a sync.Once, if you can't avoid calling the loader twice. >> >> -- >> 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...@googlegroups.com <javascript:>. >> 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
