Re: Size of fhandler_fifo

[Ken Brown <kbrown@cornell.edu>]

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