RFR 8245194: Unix domain socket channel implementation

[Michael McMahon]

On 28/08/2020 15:24, Alan Bateman wrote:
> On 24/08/2020 10:58, Michael McMahon wrote:
>>
>> Thanks for the review. Just on the Win32 variant, 
>> getPathForWin32Calls seems to return a Unicode/wide character string, 
>> but the windows API expects UTF-8. Also, it normalizes the path 
>> including converting to absolute form. (Haven't checked, but maybe 
>> getByteArrayForSysCalls does that too). But, we need to support 
>> relative paths in this API, given the severe constraints on the 
>> length of Unix domain socket names. There probably is still an issue 
>> with the right character set being used. So, I will look into fixing 
>> that (maybe by adding suitable methods to WindowsPath and UnixPath if 
>> necessary).
> The UnixPath implementation uses relative paths, except for the corner 
> case where user.dir isn't the working directory. Windows is more 
> complicated because of long paths and other reasons. It Windows has 
> the same 100 byte or char limit then it just limits the addressing. 
> I'm surprised it uses UTF-8 when the Win32 uses Unicode (at least for 
> the W variants). I see you have updated webrev on this and I will try 
> to get to that soon.
>
> -Alan.

Thanks. I notice that the limit for Windows "long" paths is 247 chars 
(bytes?). Either way, it is way longer than the approx. 100 byte 
(UNIX_PATH_MAX) limit on Unix domain socket names. sockaddr_un on 
Windows has sun_path as a char[] rather than wchar[] and the docs 
describing the API refer to UTF-8 being used. Given the limitation on 
length it probably makes sense. Though I have yet to try creating a 
socket with a name other than from regular ASCII chars. I do think we 
should support relative paths on all platforms. I have already run into 
problems with the length of absolute paths on some test systems being 
longer than the UNIX_PATH_MAX limit.

- Michael.