The old SpinLockAsMutex was pretty confusing first of all. It also was
causing the issue thats been around for maybe a year now which is the
only consistently happening kernel panic. I've been pretty confused
about this and finally figured out what was causing this.
The main issue was that we were accidentally enabling interrupts when
blocking a thread that passed SpinLockAsMutex from normally interrupt
enabled context. This led to receiving IPI for thread unblock while
we were actively blocking the thread. I'm very suprized this had't
caused any more serious issues than occasional kernel panics :^)
Update dtv[0] to the max loadad module when loading dynamic modules
Free uthread if stack allocation or mprotect fails on pthread_create
Don't unmap the currently used stack when detached thread exits
This supports most(?) options except for the separate fields. Should
work for simple use cases
Also merge is currently just a wrapper around sort so its not optimized
:D
Don't wake up threads when getting the next timer deadline.
If we are idling this can: remove thread from block list, get the
deadline for the next blocked thread, return to idle thread. This will
end up sleeping until the next wake up condition which in the worst
case would be rebalance, or indefinitely when not running SMP.
Make sure we always set the next timer deadline. I was not doing that if
the timer interrupt did not lead to a yield
Scheduler will now set a timer interrupt deadline for when it should get
interrupted next. This fixes a big issue I've had for a long time where
sleeping on an idle core would have to wait for the next periodic
interrupt to wake up. This could cause 1 ms sleeps to be close to 10 ms.
This currently only supports lapic timers and will still fallback to
periodic interrupts when running with PIC. I should add deadline support
to PIT/HPET but why would you run with APIC disabled ;)
Remove random template and just make qsort be a wrapper around qsort_r
Recurse only into the smaller partition. This removes the possibility of
O(n) recursion in the worst case
Use insertion sort for ranges shorter than 16 elements.
Split qsort_swap into qsort_swap_fixed and qsort_swap_general
- fixed one handles 1, 2, 4 and 8 byte elements which can be done directly
with mov instructions
- general copies 64 bytes at a time followed by a single copy for the
rest. the 64 byte chunk loop gets nicely optimized into sse
Bananymous