Size of fhandler_fifo

Size of fhandler_fifo

[Ken Brown]

Hi Corinna,

This is a followup to your question on IRC about why fhandler_fifo is so big. 
The main reason is the pipe_name_buf member, which occupies 96 bytes and stores 
the Windows named pipe name.

There's a similar need to store the pipe name for the fhandler_socket_unix 
class.  In that case you used pc.{set,get}_nt_native_path.  But the latter is 
already in use in the fhandler_fifo case, so I can't use that.  I see several 
possible ways to proceed:

0. Do nothing and live with fhandler_fifo being big (736 bytes on 64-bit).

1. Don't store the pipe name; just regenerate it whenever it's needed.

2. Add members to path_conv to handle pipe names, analogous to wide_path and 
uni_path.  This increases the size of path_conv from 336 to 360 on 64-bit (one 
pointer and one UNICODE_STRING).

3. Imitate in fhandler_fifo what's done in path_conv.  So we would replace 
'WCHAR pipe_name_buf[48]' by 'PWCHAR pipe_name_buf' and then malloc space for 
the pipe name.

These all have disadvantages.

#2 increases the size of path_conv for the sake of one class (although 
fhandler_socket_unix could use it too).  #3 requires fhandler_fifo to deal with 
a lot of malloc/free/strdup details that are normally handled by path_conv and 
are hidden from fhandler classes.

Ken

Re: Size of fhandler_fifo

[Ken Brown]

On 11/7/2020 10:19 AM, Ken Brown via Cygwin-developers wrote:
> Hi Corinna,
> 
> This is a followup to your question on IRC about why fhandler_fifo is so big. 
> The main reason is the pipe_name_buf member, which occupies 96 bytes and stores 
> the Windows named pipe name.
> 
> There's a similar need to store the pipe name for the fhandler_socket_unix 
> class.  In that case you used pc.{set,get}_nt_native_path.  But the latter is 
> already in use in the fhandler_fifo case, so I can't use that.  I see several 
> possible ways to proceed:
> 
> 0. Do nothing and live with fhandler_fifo being big (736 bytes on 64-bit).
> 
> 1. Don't store the pipe name; just regenerate it whenever it's needed.
> 
> 2. Add members to path_conv to handle pipe names, analogous to wide_path and 
> uni_path.  This increases the size of path_conv from 336 to 360 on 64-bit (one 
> pointer and one UNICODE_STRING).
> 
> 3. Imitate in fhandler_fifo what's done in path_conv.  So we would replace 
> 'WCHAR pipe_name_buf[48]' by 'PWCHAR pipe_name_buf' and then malloc space for 
> the pipe name.
> 
> These all have disadvantages.
> 
> #2 increases the size of path_conv for the sake of one class (although 
> fhandler_socket_unix could use it too).  #3 requires fhandler_fifo to deal with 
> a lot of malloc/free/strdup details that are normally handled by path_conv and 
> are hidden from fhandler classes.

These details probably aren't so bad.  I'll code this and see what it looks like

Ken

Re: Size of fhandler_fifo

[Corinna Vinschen]

On Nov  7 10:19, Ken Brown via Cygwin-developers wrote:
> Hi Corinna,
> 
> This is a followup to your question on IRC about why fhandler_fifo is so
> big. The main reason is the pipe_name_buf member, which occupies 96 bytes
> and stores the Windows named pipe name.
> 
> There's a similar need to store the pipe name for the fhandler_socket_unix
> class.  In that case you used pc.{set,get}_nt_native_path.  But the latter
> is already in use in the fhandler_fifo case, so I can't use that.  I see
> several possible ways to proceed:
> 
> 0. Do nothing and live with fhandler_fifo being big (736 bytes on 64-bit).

As I wrote on IRC, it's not that bad.  Trying to keep the size of
fhandlers low is probably a bit old-fashioned anyway.  32 bit trauma :)


Corinna