Exposing the switcher's thread operations to applications
This subsystem keeps track of thread ancestry and groups (could
it?), and allows its blocking operations to use handles. It
also provides the exec functionality, since it must be
aware of the first thread started, um, no, the switcher (or summat)
will have to inform it when all the threads have been wiped out due
to an exec… Needs more thought.
This is essentially a SWI exposition of the switcher's thread and process operations. However, the thread manager maintains more information about threads than the switcher, and this is also reflected in the operations.
| Type | Routine |
|---|---|
| SWI operation | ThreadManager_Fork |
| SWI operation | ThreadManager_Exec |
| SWI operation | ThreadManager_Exit |
| SWI operation | ThreadManager_Wait |
| SWI operation | ThreadManager_Spawn |
| SWI operation | ThreadManager_Finish |
| SWI operation | ThreadManager_Join |
Duplicate the current process
The current process is forked, i.e. all subcontexts of the current process are duplicated. The call returns twice: for the parent, the process id of the child is returned; for the child, zero is returned.
This routine first calls ContextSwitcher_Fork, which then calls Subsystem_Fork on each subsystem, and then duplicates the SVC stack.
Replace program image
[Edit:
Um, not entirely sure how this one is supposed to work, yet.
Perhaps it's just a matter of getting OS_FSControl,2
to clear all the thread information (which would ensure
Subsystem_Terminate was
called on all subsystems blocked on those threads).
Why is that functionality in OS_FSControl,2 anyway?
Ideally, FileSwitch (and other subsystems) should surely get a
signal from a central component (the switcher?) which they have
registered with. However, for backwards compatibility, it will
probably have to stay here.
]
All threads in the current process are terminated. All subcontexts [Edit: except memory?] are otherwise preserved.