Skip to content

Determine if context can actually be movable #90

Closed

Description

@kammce

There are a number of potential bugs that can occur when an async::context is moved. If the following problems below cannot be fixed, then context will have to become immovable once again.

1. Stack pointer invalidation

Currently the stack pointer object is located within the context object. When a coroutine's frame is allocated on the context's stack, the first word is set to the address of the stack pointer. The problem with this, is that the address becomes invalid the moment you move the context and the stack pointer's address is no longer where it was before. I

n order to prevent this invalidation, we need to put the stack pointer somewhere where it is always accessible by the context stack. My initial suggestion is to make the 1st word in the stack the stack pointer. We must also add documentation that makes it very clear that the memory provided to a stack must not be moved/relocated if its not empty. When one coroutine calls the next, it may have passed a reference or address to the called coroutines and those address need to not change underneath those coroutines.

Proxies will simply start their own stack with their stack pointer at the top of the stack. Same as before but stored on the stack.

Note

This will reduce the context size by one word, ensuring that its within a 8-word cache line

2. Proxies

Proxies currently cannot be moved so thats not a problem. But if the original is moved, then the m_original pointer will be invalidated. This might be the killer that makes context no longer movable.

Activity

  1. changed the title [-]Make context fully movable[/-] [+]Determine if context can actually be movable[/+] on Apr 1, 2026
  2. kammce commented on Apr 19, 2026

    @kammce
    MemberAuthor

    It cannot, and that was resolved in #92

  3. kammce commented on Apr 19, 2026

    @kammce
    MemberAuthor

    We could, but as it stands now, we could keep the variable with the context for fast access. Placing the stack pointer on the stack results in an additional indirection from context::span.m_data[0] and add maintance complexity. Will skip this for now until its needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions