FutureTask.cancel(true) should run thread.interrupt within doPrivileged

[David Holmes]

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 <david.holmes at oracle.com>wrote:
>
>> On 3/10/2013 1:55 PM, Martin Buchholz wrote:
>>
>>> On Wed, Oct 2, 2013 at 7:13 PM, David Holmes <david.holmes at oracle.com>**
>>> wrote:
>>>
>>>   On 3/10/2013 2:54 AM, Martin Buchholz wrote:
>>>>
>>>>   On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart <peter.levart at gmail.com>
>>>>> 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
>>
>>