-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: make sure we instantiate non-main modules #93
Conversation
@@ -251,8 +254,6 @@ func (p *CompiledPlugin) Instance(ctx context.Context, config PluginInstanceConf | |||
if err != nil { | |||
return nil, fmt.Errorf("failed to initialize Observe Adapter: %v", err) | |||
} | |||
|
|||
trace.Finish() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
calling Finish
on the trace context right after creating it didn't make sense (we're storing the trace context in the plugin struct), so i removed the call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also a line:
moduleConfig = moduleConfig.WithName(strconv.Itoa(int(p.instanceCount.Add(1))))
It seems to be redundant now + p.instanceCount
also can be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm, i am not sure, the comment for p.instanceCount
suggests otherwise. @evacchi what do you think? I moved the naming closer to the main module initialization to make it clearer that this naming is for the main module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, you are correct, InstantiateModule
comment states that module name can't be reused, this probably also means that other modules can't be instantiated multiple times?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC not with the same name, within the same runtime
@mymmrac thank you very much for the review! |
@mymmrac i found a way to make module linking work with multiple modules by wrapping the non-main modules in a host module. Can you please test this and see if it works with your use case too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
holy moly that's actually quite clever 😅 I wonder if there is a perf hit and/or we should allow to opt-in this behavior, but in general it seems like a cool workaround :D
@evacchi good point, i will try to run a benchmark on sunday. I was also thinking maybe we implement both? and do one or the other depending if it's necessary. For example, if the user only needs one instance or if they only have one module, we don't need to do any of this (which is probably 90+% of the cases). So if there is a perf hit, we certainly can consider that too |
yeah that makes sense, we could just make it a flag |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Very clever solution, it adds a little bit of overhead when calling linked modules, but since it's not very common to have many modules (at list I think so) this is good for our case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(deleted, see comment in code)
runtime.go
Outdated
func detectGuestRuntime(p *Plugin) guestRuntime { | ||
runtime, ok := haskellRuntime(p, p.mainModule) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the issue with Big Go is that we are really only initializing the main module, dependency are still not being initialized 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(working on a patch...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhmd-azeez I pushed a commit to this branch (feel free to revert or iterate if you think it's appropriate) with a fix. The issue that I can foresee is that, if there are cross-dependencies between modules, then the init order is random! The "proper" way to init dependencies would be to linearize the dependency graph and then initialize it in that order. We can do that in a follow-up, though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
Signed-off-by: Edoardo Vacchi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix for modules compiled with Go 1.24 works, thanks
The benchmarks don't show a significant difference for the normal case, so I am going to merge the PR and we can schedule any additional work in a new PR main:
fix_module_linking:
|
Fixes #92