- Feb 18, 2018
- Feb 14, 2018
-
-
Lioncash authored
-
- Jan 09, 2018
- Jan 03, 2018
-
-
bunnei authored
-
- Dec 31, 2017
-
-
bunnei authored
This is kinda crufty, but we need it for now to update guest state variables.
-
- Dec 30, 2017
- Dec 29, 2017
-
-
bunnei authored
-
- Oct 31, 2017
-
-
bunnei authored
-
- Oct 20, 2017
-
-
bunnei authored
-
- Oct 10, 2017
-
-
bunnei authored
-
- Oct 01, 2017
-
-
Subv authored
-
- Sep 30, 2017
-
-
bunnei authored
-
Huw Pascoe authored
-
- Sep 28, 2017
-
-
Subv authored
This change makes for a clearer (less confusing) path of execution in the scheduler, now the code to execute when a thread awakes is closer to the code that puts the thread to sleep (WaitSynch1, WaitSynchN). It also allows us to implement the special wake up behavior of ReplyAndReceive without hacking up WaitObject::WakeupAllWaitingThreads. If savestates are desired in the future, we can change this implementation to one similar to the CoreTiming event system, where we first register the callback functions at startup and assign their identifiers to the Thread callback variable instead of directly assigning a lambda to the wake up callback variable.
-
- Sep 26, 2017
-
-
Subv authored
Don't automatically assume that Thread::Create will only be called when the parent process is currently scheduled. This assumption will be broken when applets or system modules are loaded.
-
- Sep 24, 2017
-
-
MerryMage authored
Don't expose Memory::current_page_table as a global.
-
- Sep 15, 2017
-
-
Subv authored
Kernel/Threads: Don't clear the CPU instruction cache when performing a context switch from an idle thread into a thread in the same process. We were unnecessarily clearing the cache when going from Process A -> Idle -> Process A, this caused extreme performance regressions.
-
- Sep 10, 2017
-
-
Subv authored
-
- Aug 22, 2017
-
-
Subv authored
This is necessary for loading multiple processes at the same time. The main thread will be automatically scheduled when necessary once the scheduler runs.
-
- Jun 19, 2017
-
-
Yuri Kunde Schlesner authored
Replace it with std::move(result_val).Unwrap(), or Foo().Unwrap() in case you already have an rvalue.
-
- May 30, 2017
-
-
Yuri Kunde Schlesner authored
-
- May 25, 2017
-
-
Yuri Kunde Schlesner authored
-
- Jan 11, 2017
- Jan 06, 2017
-
-
Subv authored
Kernel: Don't attempt to yield execution in SleepThread(0) if there are no available threads to run. With this we avoid an useless temporary deschedule of the current thread.
-
- Jan 05, 2017
-
-
Subv authored
-
Subv authored
After hwtesting and reverse engineering the kernel, it was found that the CTROS scheduler performs no priority boosting for threads like this, although some other forms of scheduling priority-starved threads might take place. For example, it was found that hardware interrupts might cause low-priority threads to run if the CPU is preempted in the middle of an SVC handler that deschedules the current (high priority) thread before scheduling it again.
-
Subv authored
-
Subv authored
Kernel: Remove Thread::wait_objects_index and use wait_objects to hold all the objects that a thread is waiting on.
-
- Jan 04, 2017
-
-
Subv authored
Kernel: Use different thread statuses when a thread calls WaitSynchronization1 and WaitSynchronizationN with wait_all = true. This commit removes the overly general THREADSTATUS_WAIT_SYNCH and replaces it with two more granular statuses: THREADSTATUS_WAIT_SYNCH_ANY when a thread waits on objects via WaitSynchronization1 or WaitSynchronizationN with wait_all = false. THREADSTATUS_WAIT_SYNCH_ALL when a thread waits on objects via WaitSynchronizationN with wait_all = true.
-
Subv authored
Kernel/Mutex: Propagate thread priority changes to other threads inheriting the priority via mutexes
-
Subv authored
The implementation is based on reverse engineering of the 3DS's kernel. A mutex holder's priority will be temporarily boosted to the best priority among any threads that want to acquire any of its held mutexes. When the holder releases the mutex, it's priority will be boosted to the best priority among the threads that want to acquire any of its remaining held mutexes.
-
Subv authored
This will be useful when implementing mutex priority inheritance.
-
- Dec 22, 2016