On 3/10/2013 2:11 PM, Martin Buchholz wrote:
I was responding to Peter Levart's suggestion of checking for the presence
of a security manager before calling doPrivileged. Which is not an
important question now, given that the primary question is whether we
should allow future.cancel() to interrupt within a doPrivileged.
Ah I see.
Alternatively, is there a reasonable way for a security manager to enable
such usages without enabling arbitrary modifyThread?
I'm not quite sure what you are asking. Thread permissions are
notoriously coarse-grained. I thought that was a big mistake when the
security architecture was updated in 1.2 (?) but here we are a decade
(or more) later and it seems noone really complained. So be it.
Hypothetically we could define finer-grained permissions to differ
interrupt from nasty things like stop/suspend. But in practice unless we
change how we assign that permission then you would still require it and
wouldn't have it unless using a custom security policy - which would
allow you to deal with the modifyThread permission too.
David
-----
On Wed, Oct 2, 2013 at 9:03 PM, David Holmes <[email protected]>wrote:
On 3/10/2013 1:55 PM, Martin Buchholz wrote:
On Wed, Oct 2, 2013 at 7:13 PM, David Holmes <[email protected]>**
wrote:
On 3/10/2013 2:54 AM, Martin Buchholz wrote:
On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart <[email protected]>
wrote:
Hi Martin,
If you want to optimize for without-security-manager case
I want to optimize for the case that Thread.interrupt does not throw
SecurityException
How is your proposal optimizing that case ???
Instead of doing extra work to avoid a SecurityException, I am assuming a
SecurityException is rare, and risk having to throw it twice.
Sorry I'm missing something - what extra work are you avoiding and where?
The original code just did t.interrupt() now you've added try/catch with a
second privileged interrupt attempt. I don't see anything being avoided.
Are you referring to caller code that catches the SecurityException itself
and somehow retries?
David
