Re: deferred cancellation of ipc

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> Maybe you want to consider the following solution, which might be
> acceptable.  Plus it is simple.

Stopping the thread while figuring out what it's doing seems like the
right thing to do. I think that's where the simplicity comes from.

For simplicity, I'd suggest that you skip the yield part, and just
have a loop sleeping one or a few timeslices at a time. The reason
that should work is that when we wake up either

  1. The blocking thread hasn't reached the ipc call yet. Then we
     have to sleep some more and try again.

  2. The target thread is blocking in the ipc. Then we can cancel it
     right away.

  3. The target thread has finished the ipc. Then we can just return;
     the target thread will notice thread_var_ipc_cancel == 1 the next
     time it tries an ipc, which may in fact have happened already.

(I'm still tempted to suggest using some low-level trickery (like
 examining the IP and modifying it if it's before the system call), in
 case the stopped target thread is not currently in the ipc system
 call. The main advantage would be that the cancellation function
 would never block. But if works fine to go to sleep for a timeslice,
 then the problem is solved and clever optimizations can be postponed
 for later).

> Another thing: If two threads try to cancel another thread at the same time,
> I don't think it will work out too well.  Mutual exclusion is required, for
> the stop/start of the thread alone, if not for any other reasons.

One should keep that mutex locked for the entire duration of the
cancellation function, including sleep time, right? If we accept that
cancelling a thread may block for a short while, then it doesn't
really matter if we block on l4_sleep or on mutex_lock, so I don't
think that is a big deal. It makes sense to have a per-thread mutex
that protects the thread control state.

Regards,
/Niels