Skip to content
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

Closed
vicuna opened this issue Jul 16, 2013 · 4 comments
Closed

Lazy initialization of dynlinked plugins #6079

vicuna opened this issue Jul 16, 2013 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Jul 16, 2013

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

@vicuna
Copy link
Author

vicuna commented Jul 17, 2013

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.)

@vicuna
Copy link
Author

vicuna commented Jul 17, 2013

Comment author: @diml

I updated the patch to raise an exception in this case.

@vicuna
Copy link
Author

vicuna commented Jan 21, 2014

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).

@vicuna
Copy link
Author

vicuna commented Jan 5, 2017

Comment author: @diml

Initially we wanted this for ocaml_plugin. Currently we wrap the user code inside a functor so that:

  1. we can delay the execution of the toplevel code (i.e. what this patch implements)
  2. we can check that the exe and plugins agree on types before running the user code

This patch would only give us (1) and is low-priority so I'm suspending this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant