Repository navigation
Store Rust stdlib modules on VirtualMachine and lazily-load them - #107
Conversation
This means we only have to load the modules once at startup. Fixes RustPython#90.
OddBloke
changed the title
| pub fn get_modules(vm: &VirtualMachine) -> HashMap<String, PyObjectRef> { | ||
| pub type StdlibInitFunc = fn(&PyContext) -> PyObjectRef; | ||
|
|
||
| pub fn get_module_inits() -> HashMap<String, StdlibInitFunc> { |
There was a problem hiding this comment.
I would expect here HashMap<String, PyObjectRef> where the object refers to a python module instance.
| frames: Vec<Frame>, | ||
| builtins: PyObjectRef, | ||
| pub sys_module: PyObjectRef, | ||
| pub stdlib_inits: HashMap<String, stdlib::StdlibInitFunc>, |
There was a problem hiding this comment.
Maybe we can make the rust parts of the stdlib part of context, so when we have more than 1 vm, the stdlib is shared. Does this make sense?
There was a problem hiding this comment.
I see no reason why this couldn't live on PyContext instead of VirtualMachine.
| // Check for Rust-native modules | ||
| if let Some(module) = stdlib::get_modules(vm).get(module) { | ||
| return Ok(module.clone()); | ||
| if let Some(module) = vm.stdlib_inits.get(module) { |
There was a problem hiding this comment.
Maybe it is a good idea to implement some sort of function which get_or_create's a module based on a name. This function then will check a cache HashMap<String, PyObjectRef> where the object ref is a module ref, and if not present, calls an init function on the module, so it is loaded lazily. On the other hand, we might preload all builtin modules, so that the initialization order is deterministic at all times.
There was a problem hiding this comment.
Isn't that cache just sys.modules?
(We don't currently put anything in there, see #109.)
There was a problem hiding this comment.
Ha! I totally forgot about that, you are right!
This means we only have to load the modules once at startup.
Fixes #90.