dimensionalOS / dimensionalOS/dimos
Single process ends up hosting heavy modules
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 4.5k
- Forks
- 808
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 233
Description
some of our modules are extra GIL heavy - connection for unitree, rerun bridge, those should never be in the same process. some of our modules are extra light and we can host 20 in the same process.
should we fork a single process per module, given linux does copy on write, what is the actual impact on RAM here or optimal strategy for importing py libs pre-fork? investigate
alternatively, and unfortunately, should we tag modules in some way (auto-profile auto-tag even?) so that we can distribute them across processes better?
Synced from DIM-780 by summer
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by measuring memory and import behavior for the Unitree connection and Rerun bridge under Linux, comparing one process per module with grouped modules and pre-fork imports. Done means a documented process-allocation strategy, including whether automatic module tagging is needed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, python
- Domain
- backend, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100