[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deferred cancellation of ipc

From: Marcus Brinkmann
Subject: Re: deferred cancellation of ipc
Date: Tue, 14 Oct 2003 13:36:12 +0200
User-agent: Mutt/1.5.4i

On Tue, Oct 14, 2003 at 09:44:35AM +0200, Niels M?ller wrote:
> Can one use the exchange registers to fake a function call in the
> target thread? It should be possible to change the IP I guess, but
> perhaps harder to save the return address.

Yes, that's one of the things ExchangeRegisters is good for.
> Perhaps something like this could work?

Looks not too bad at all.

> A different race remains: If the thread is cancelled after the l4_ipc
> system call has returned to user space, but before the line marked X
> above, the returned value from the ipc is lost and the caller will
> think it was cancelled.

Yes, that popped up in some of the things I considered as well.

> What we need here is for in_hurd_ipc to
> cleared atomically, as the l4_ipc system call remains; almost anything
> that's tied to thread ipc operations could work; a flag that's cleared
> on ipc completion, or a counter of completed ipc, ...
> Ahh, one idea just struck me: When cancelling a thread, install a
> redirector for the thread.

That's very expensive.  It's a whole IPC to the privileged server, and of
course might block itself! :)

> Then you can force all send ipc:s to fail
> quickly, but it doesn't help for receive rpc:s, so perhaps you
> considered that already. One nice thing is that the "forgot about
> successful ipc" race is less serious for recv operations.

It's not really less serious, because the sender will not know that you
ignored the received messages, which also might contain map or grant items.
This is a robustness issue of course.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]