Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006079OCamlotherlibspublic2013-07-16 13:262017-01-05 16:07
Assigned Todim 
PlatformOSOS Version
Product Version4.00.1 
Target VersionFixed in Version 
Summary0006079: Lazy initialization of dynlinked plugins
DescriptionThe 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.
Attached Filespatch file icon 0002-lazy-initialization-of-dynlinked-plugins.patch [^] (7,244 bytes) 2013-07-17 13:01 [Show Content]

- Relationships

-  Notes
frisch (developer)
2013-07-17 10:34

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.)
dim (developer)
2013-07-17 13:02

I updated the patch to raise an exception in this case.
frisch (developer)
2014-01-21 11:55

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).
dim (developer)
2017-01-05 16:07

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.

- Issue History
Date Modified Username Field Change
2013-07-16 13:26 dim New Issue
2013-07-16 13:26 dim Status new => assigned
2013-07-16 13:26 dim Assigned To => dim
2013-07-16 13:26 dim File Added: 0002-lazy-initialization-of-dynlinked-plugins.patch
2013-07-17 10:34 frisch Note Added: 0009795
2013-07-17 13:01 dim File Deleted: 0002-lazy-initialization-of-dynlinked-plugins.patch
2013-07-17 13:01 dim File Added: 0002-lazy-initialization-of-dynlinked-plugins.patch
2013-07-17 13:02 dim Note Added: 0009796
2014-01-17 16:07 doligez Tag Attached: patch
2014-01-21 11:55 frisch Note Added: 0010820
2014-08-21 12:04 doligez Target Version 4.02.0+dev =>
2017-01-05 16:07 dim Note Added: 0017078
2017-01-05 16:07 dim Status assigned => resolved
2017-01-05 16:07 dim Resolution open => suspended
2017-02-23 16:42 doligez Category OCaml otherlibs => otherlibs

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker