Size of fhandler_fifo
Ken Brown
kbrown@cornell.edu
Sun Nov 8 13:11:51 GMT 2020
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
More information about the Cygwin-developers
mailing list