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.
