[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 8241829 Cleanup the code for PrinterJob on windows
From:       Philip Race <philip.race () oracle ! com>
Date:       2020-04-07 22:27:26
Message-ID: 5E8CFE4E.5090909 () oracle ! com
[Download RAW message or body]

Looks good. No way to test this now. Fingers crossed.

phil.

On 4/7/20, 2:49 PM, Sergey Bylokhov wrote:
> On 4/7/20 1:40 pm, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> Looks good to me.
>>
>> Yet I don't quite understand the test. Does the test confirm, no 
>> print services are returned if a SecurityManager is installed?
>
> Yes, I added it just to confirm my assumptions.
>
>>
>>
>> Regards,
>> Alexey
>>
>> On 05/04/2020 02:40, Sergey Bylokhov wrote:
>>> Hello,
>>>
>>> Here is an updated patch:
>>> http://cr.openjdk.java.net/~serb/8241829/webrev.02
>>>
>>> Some thoughts about the patch:
>>>  - The memory leak mentioned before is not really critical. It has
>>>    occurred only if some exception is happening, otherwise, the
>>>    loop worked till the end of the JVM, because this is infinite
>>>    loop on the daemon thread.
>>>
>>>  - The old loop tried to catch SecurityException which as far as I
>>>    understand cannot be happen, since the thread has all 
>>> permission(it is
>>>    started in the doPriv block). The similar loop for remote printers
>>>    does not have such "catch SecurityException" as well.
>>>
>>>  - I have re-implement the loop in the native code and mimic the old
>>>    behavior, and this highlight some other issues: Should we exit when
>>>    java exception occur, should we exit if 
>>> "FindNextPrinterChangeNotification"
>>>    or "WaitForSingleObject" return some errors? The example in the msdn
>>>    does not exit in such cases[1].
>>>
>>> [1] 
>>> https://docs.microsoft.com/en-us/windows/win32/printdocs/findnextprinterchangenotification
>>>
>>> On 4/2/20 12:09 pm, Sergey Bylokhov wrote:
>>>> On 4/2/20 12:00 pm, Philip Race wrote:
>>>>>
>>>>> Are we leaking the handle ?  Looks that way to me .. 
>
>
[prev in list] [next in list] [prev in thread] [next in thread]