Skip to content

Instantly share code, notes, and snippets.

@wolfwood
Last active December 17, 2015 01:58
Show Gist options
  • Save wolfwood/5531973 to your computer and use it in GitHub Desktop.
Save wolfwood/5531973 to your computer and use it in GitHub Desktop.
hokay, so .... the kernel's job is just to return an activation to userspace at a well known entry point, so the userspace can context switch itself and then tell The Authorities that An Intarrupt Has Occurred.
sooooo,
first : we need to know if the thing we interrupted is a thread:
- modify get current thread to use a magic number to recognize if the suspended RSP is a valid stack
- kernel sets null rsp upon reentering userspace... no stack at all means no thread
- stackless context switcher code must be idempotent - if interrrupted, does the same thing the interrupted code was doing
- what about stackless thread scheduler? we may have dequeued a thread to run but not be on its stack yet :(
if it is a thread:
a) be lazy
1) set a bit to resume thread from activation, and note activation address in thread struct (instead of the normal thread entry with the now-stale rsp saved in the thread struct)
2) yield to parent environment (with a message indicating the interrupt as the reason for control transfer)
b) clean up activation
1) redzone size is capped, copy activation to stack below redzone
2) push a resume thread function to stack
3) modify thread rsp to resume as normal
4) requeue thread for later scheduling
5) mark activation as unused
6) yield to parent environment
if it isn't a thread:
a) treat as a critical section and resume doing what we were doing (with assuming some check at the end to alter control flow and yield to parent)
b) make a thread to suspend it to so we can resume it? (stackless thread create == :((((( )
c) stacklesss thread scheduler also tracks activations to resume with a higher priority than threads?
option a) exploits the reason we wanted to do userspace controlled context switches to begin with
option b) is basically a nonstarter.... maybe with enough preallocated state we could make it work... until we have nested stackless resumes :(
option c) is maybe reasonable, and should at least be able to handle nesting without frothing at the mouth, assuming we don't resume in the middle of an activation chain
what are stackless things we could be doing?
- yield thread, enter thread scheduler
- yield CPU to parent -this is what we want to do, but perhaps with a different payload
- yield CPU to child - if we are doing this on a thread's behalf, it would be important to know it never actually happened
- handling an activation for a thread
- handling an activation for a not-thread
- recieving a yield from child or parent... yield from child may already be carrying an interrupt. which one wins? can we merge em?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment