To at least partially answer my own question, I think that the answer is that the socket can't be closed (at least in all cases).
If the delegate for a resource has multiple users (codebases, principals, etc.) then closing the resource because permission for one of the users has been revoked denies access to the resource by the remaining valid users. (This allows a denial of service attack.) And then, if you can't close the resource (socket), you can't kick loose the no longer trusted thread blocked reading from it. You may be able to determine the special case of no user retaining access (everyone's access was revoked) and can then close the resource. In the standard security model, there are no checks for reading/writing sockets. Allowing revocation means that checks must be added for each individual read or write call on the socket streams. Is that level of performance satisfactory? > If there is untrusted code on a thread's stack, and if the thread > called a delegate, and if the delegate is in the between ECM.begin() > and ECM.end(), then the delegate's reaper will be called, and it can > close the socket. > > If the revocation happened elsewhere (e.g. the untrusted code is not > on any stack, or is occupied with some other task), how does the > socket get closed? > > Fred
