add an ability to execute a callback function on behalf of target coroutine stack right before return to target coroutine
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- operating-systems
Research direction
The issue names no files or tests; begin by locating jump_fcontext and its assembly implementation. Review the proposed transfer_t signature and the shown post-RSP callback sequence, then define done as implementing and validating that callback contract and its stack-lifetime behavior.
Written by the indexing model from the issue text.
Description
rational
when do "jump_fcontext", we have an opportunity to pass "void*" to target coroutine. how to do with that argument is up to the target coroutine.
some time we do want to do some 'clean up job' right before return to the target coroutine. because there exist some task that must not be executed on current stack. for example , free current stack memory.
and for muti-threaded environment, we do need a way to distinguish where a context-switch is finished.
by changing jump_fcontext to transfer_t jump_fcontext( fcontext_t const to, void * vp, transfer_t (* fn)( fcontext_t from, void*));
we can now:
- pass a cleanup function to clean stack right after stack pointer got swapped.
- notify the scheduler that "from coroutine context" is now safe to be used as "to coroutine".
- record "from" that does not relay on jumpee coroutine to do the job. that makes code cleaner and easy to understand.
- doing things before return to target is a bit faster. because the registers are not restored and then saved-again by "the code that called when jump_context returns" with is in fact doing things for previous coroutine.
changes to the assembly code
right after loading RSP from "to".
add this lines
test %rdx, %rdx // test for 3th argument, aka callback_fn
je skip_call
mov %rax, %rsi // pass from:fctx argument to callback_fn as first argument, %rdi is already the same argument
call * %rdx // call callback_fn, and use its result as return , do not touch %rax:%rdx pair.
skip_call:
// original code that retore registers
- Dominant language
- Assembly
- Stars
- 371
- Forks
- 186
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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.
More from boostorg/context
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Support for the PACOpen
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 42/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
All issues in boostorg/context
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
siderolabs/pkgs#1710 ·
Maintainers usually reply within 1 day
-
good first issue kernel
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
JackFurton/who-would-build-a-kernel-in-java#81 ·
Maintainers usually reply within 1 day
-
[BUG] Windows: per-process values that can't be read (handles, I/O, network) still show as 0, not N/APossibly taken A pull request linked to this issue is open or already merged. Openagent:Windows bug MEDIUM windows
Difficulty 2/5 Half a day Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
app bug sandbox windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
openai/codex#50915 · 1 reaction ·
Maintainers usually reply within 1 day