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
Lazy initialization of dynlinked plugins #6079
Comments
Comment author: @alainfrisch Is this API really safe? If a plugin A is dynlinked but not yet initialized and another plugin B which depends on A is then dynlinked, it could access components from A which are not yet available. (There is probably some opportunity for similar problems with the current API when real threads are used, but this is fine: the stdlib is not advertised as being thread-safe.) |
Comment author: @diml I updated the patch to raise an exception in this case. |
Comment author: @alainfrisch What happens when the initialization code raises an exception? In the previous version, this was caught by the handler around the call to Meta.reify_bytecode, and the symbol table was reverted to its initial state. (If an exception is raised, has the symbol table been extended? I don't think so, but this means that the previous code was useless. This should be clarified.) Similarly, the call to Symtable.hide_addition in loadfile_private is now executed before the initialization code. But I believe this code is the one which extends the set of globals, which would mean the current logic is broken (i.e. the additions are not hidden). |
Comment author: @diml Initially we wanted this for ocaml_plugin. Currently we wrap the user code inside a functor so that:
This patch would only give us (1) and is low-priority so I'm suspending this issue. |
Original bug ID: 6079
Reporter: @diml
Assigned to: @diml
Status: resolved (set by @diml on 2017-01-05T15:07:45Z)
Resolution: suspended
Priority: low
Severity: feature
Version: 4.00.1
Category: otherlibs
Tags: patch
Bug description
The attached patch adds two functions to the Dynlink module: loadfile_lazy and loadfile_private_lazy. They return a lazy value that execute the initialization code of the plugin when forced.
The goal is to be able to separate the blocking part (dlopen) from the initialization code. This is especially useful for programs using lwt or async as it is important not to block the main thread.
File attachments
The text was updated successfully, but these errors were encountered: