Is there any reliable way to determine if a thread is suspended? seL4_TCB_Suspend() succeeds even if the thread was already suspended. I can force all calls to seL4_TCB_Suspend() and seL4_TCB_Resume() to go through a wrapper that updates a user-level flag (since my OS manages pretty much all capabilities in the root server and will only expose TCBs to regular user processes through a special filesystem); however, this leaves a race when a thread is suspended due to a fault instead of an API call (since the thread will already be suspended before the fault handler updates the "thread running" flag). My initial use for checking if a thread is running is to allow easy atomic updates of some metadata (shared between the root server and the non-root thread, and optionally shared between threads) for my IPC transport layer that implements Unix-like file descriptors on top of seL4 endpoints (and eventually notifications). To add an FD to a thread's list, the root server allocates a copy of the endpoint (and reply if the FD is server-side) into the thread's CSpace, suspends the thread, updates the metadata (which includes the underlying capabilities), and then resumes the thread if it was running. Obviously, I don't want to resume threads that weren't running in the first place. I don't want to use locks here since the root server can't trust regular user processes. Another use is to allow cancelling any in-progress transfers on FDs when they get closed and returning a status to the waiting threads, which I am planning to do by replacing the endpoint with a copy of a global "clunk endpoint" associated with a thread that repeatedly sends a "file descriptor closed" message (actually there will be two such threads - one for clients, and one for servers) and then resuming the thread.