FutureTask.cancel(true) should run thread.interrupt within doPrivileged
Martin Buchholz
martinrb at google.com
Thu Oct 3 04:11:01 UTC 2013
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.
Alternatively, is there a reasonable way for a security manager to enable
such usages without enabling arbitrary modifyThread?
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20131002/d3454c2b/attachment.htm>
More information about the security-dev
mailing list