Mill Computing, Inc. Forums The Mill Architecture IPC questions

  • Author
    Posts
  • Findecanor
    Participant
    Post count: 9
    #3067 |

    I have a few questions about the Portal call mechanism:

    1. What happens if a callee of a portal call would need more than a page frame of stack?

    2. Can a temporary grant to an address region to a callee in a portal call be temporarily forwarded to a third turf or to another thread in the callee’s turf?

    3. Are portal calls compatible with C++’s exceptions?

    4. What if a caller’s turf/process has a thread that crashes and the OS decides to kill all other threads attached to that turf … but one of those other threads is in a portal call?
    I read that Sun Spring’s Door semantics would in that case make the callee finish and “return to the kernel”. I find that to be the most reasonable course of action. But how would the kernel be able to set up a different return address, trap or syscall to end the calling thread upon return?

    Thanks in advance

  • Ivan Godard
    Keymaster
    Post count: 473

    1) What happens if a callee of a portal call would need more than a page frame of stack?
    We get stack with the alloca op, and if it overflows the current remaining free space then the system grabs more. The stack is segmented, so frames do not have to be contiguous with each other. This precludes certain stack games (often exploits) but most of those are impossible anyway because the stack links are not in user space.
    2) Can a temporary grant to an address region to a callee in a portal call be temporarily forwarded to a third turf or to another thread in the callee’s turf?
    Temporary grants can be re-temporary-granted. Whether they are visible to other threads using the same turf depends on the details of the passing mechanism used by the language RTS, but the hardware does not make it easy.
    3) Are portal calls compatible with C++’s exceptions?
    Portal calls are compatible with exceptions; you can use a portal anywhere you could use a non-portal call.
    4) What if a caller’s turf/process has a thread that crashes and the OS decides to kill all other threads attached to that turf … but one of those other threads is in a portal call?
    I read that Sun Spring’s Door semantics would in that case make the callee finish and “return to the kernel”. I find that to be the most reasonable course of action. But how would the kernel be able to set up a different return address, trap or syscall to end the calling thread upon return?

    OS policy is up to the OS. The hardware spec has little to do with it, other than to make sure that all plausible IS policies are possible. Because any thread (process, portal) that is in a turf that gives the right access can access the memory where the thread info and stack links are kept then that thread/process/portal can rearrange things arbitrarily. We expect that there will be a service that has the necessary access and exports an API to do useful things (like kill a thread and recover its resources) for use by everything from kill -9 to a debugger. We’re embarked on a reference implementation, but the policies are still unsettled.

You must be logged in to reply to this topic.