RFR 6307456 : UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix)

[Ivan Gerasimov]

Thank you David!


On 3/14/19 4:48 PM, David Holmes wrote:
> Hi Ivan,
>
> This is an "ancient" bug that you are fixing. I don't think it is valid.
>
> On 15/03/2019 3:29 am, Ivan Gerasimov wrote:
>> Hello!
>>
>> Not all the man pages agree that chmod, access and statvfs64 can be 
>> interrupted, but at least on some platforms they are allowed to fail 
>> with EINTR:  chmod(2) on MacOS, access(2) on Solaris and statvfs(3) 
>> on Linux.
>>
>> So, it would be more accurate to wrap these up into a RESTARTABLE loop.
>
> When Java threads are created, or native threads attach to the VM to 
> become Java threads, they all get a very specific signal-mask to block 
> most (non synchronous) signals. The signals that we install handlers 
> for in the VM are also configured with SA_RESTART. So unless 
> specifically specified as not honouring SA_RESTART we should not need 
> the RESTARTABLE loop.
>
>
But isn't it possible to install a custom signal handler through JNI, 
omitting SA_RESTART flag?
>
> So I'm not clear exactly what signals we need to be guarding against 
> here, or whether this indicates some kind of (historic) mismatch 
> between the library and VM code?
>
grep shows that RESTARTABLE macro and its variants are used throughout 
hotspot and jdk code.
If it were possible to guarantee that no syscalls are ever interrupted, 
it would surely be much cleaner to remove all these wrappers and loops.

With kind regards,
Ivan

> Thanks,
> David
> -----
>
>> Also, java_io_UnixFileSystem_list was tiny-optimized to avoid 
>> unnecessary reallocation.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6307456
>> WEBREV: http://cr.openjdk.java.net/~igerasim/6307456/00/webrev/
>>
>> Thanks in advance!
>>
>

-- 
With kind regards,
Ivan Gerasimov