Version 1 (modified by Chandon, 11 years ago) |
---|
For the gsoc_threads branch, I plan to split the interpreter structure into two parts in order to allow for efficient parallel thread (Task) execution: one global_interpreter structure that is shared and protected by locks or other concurrent access rules and many local_interpreters that run simultaneously in separate OS threads.
For the global data, some things will need to be protected by a global lock, while other things will be read-only by default and require ever interpreter to sync up before they can be written (using the same syncing mechanism as for gc).
I'm not sure if there's actually a difference between schedulers and interpreters. With the event system gone, the scheduler PMC may simply be extraneous.
Here's my first pass at breaking things up:
Global Interp (one per Parrot)
Lock every time
- mem_pools
- gc_sys
- gc_registry
- pdb
- iglobals
- hll_info
- hll_namespace
- root_namespace
- caches
- scheduler (global)
Assume RO, sync to write
- class_hash
- vtables
- n_vtable_max
- n_vtable_alloced
- piodata
- op_lib
- op_count
- op_info_table
- op_func_table
- n_libs
- all_op_libs
- debug_flags
- run_core
- cores
- num_cores
- initial_pf
- imc_info
- output_file
- hash_seed
- op_mmd_cache
- const_cstring_table
- const_cstring_hash
- recursion_limit
dunno
- lo_var_ptr
- world_inited
- exit_handler_list
- sleeping
- thread_data
Apparently not used
- task_queue
- evc_func_table
- save_func_table
- parent_interpreter
Local Interp (One per actually-simultaneous task)
- pc (implicit)
- ctx*
- flags
- code
- dynamic_env*
- scheduler (local)
- last_alarm
- quantum_done
- current_task
- current_cont
- current_runloop
- runloop_jmp_free_list
- current_runloop_level
- current_runloop_id
* Environments will require some more thought, since one task can close over data from another.
Global Scheduler (one per Parrot)
- future alarms
- all tasks
Local Scheduler (one per interpreter)
- task queue
- next_task_id