child_send hits a 64k limit?

[xavier...@gmail.com]

I need to apply a custom filter function when pasting text. So in winclip.c I am trying to do the following:

1. intercept the paste buffer
2. read it in chunk of 40bytes
3. apply my filter function which produces other 40bytes
   
4. child_send those 40 bytes

Everything seems working fine but if I paste anything larger than 64k bytes the program freezes.

Any hint?

Regards,
Xavier

[Andy Koppe]

On Aug 9, 2:31 pm, xavier.la...@gmail.com wrote:
> I need to apply a custom filter function when pasting text. So in winclip.c
> I am trying to do the following:
>

>    1. intercept the paste buffer
>    2. read it in chunk of 40bytes
>    3. apply my filter function which produces other 40bytes
>    4. child_send those 40 bytes

Hacking mintty for this doesn't sound like a terribly good approach.
I'd paste the text into a file using a Windows editor, and then try to
use standard tools to do the filtering or write a simple filter if
that doesn't work.

> Everything seems working fine but if I paste anything larger than 64k bytes
> the program freezes.
>
> Any hint?

I'm not aware of such a limit in mintty itself. It could be a limit in
the Cygwin pseudo terminal implementation, which normally doesn't have
to deal with writes of such a size. It could also be a deadlock with
the mintty process and the application waiting for each other's output
to be read, due to limited buffering. In 'ps' that would show with
both processes marked with an 'O' in the first column.

Andy

[xavier...@gmail.com]

Hi Andy,

thanks for the adivice. Actually the true limit turned out to be 128k. The "problem" is easily reproducible. At the bash prompt in mintty I do:

$ cat > /dev/null

then I trigger this piece of code (e.g. mouse right click):

        char buf[] = "1234567890";
        for (int i=1; i<=13107; i++)  // <128k
                child_write(buf, 10);

which runs as expected. But when I change the code in:

        char buf[] = "1234567890";
        for (int i=1; i<=13108; i++)  // >128k
                child_write(buf, 10);

the program frezees.  A "ps" reveals:

I    3184    7888    3184       2132  pty0    241548 11:03:27 /usr/bin/cat
     7888    6440    7888       6596  pty0    241548 10:56:34 /usr/bin/bash
O    6440    9724    6440       1388  pty5    241548 10:56:34 /cygdrive/c/mintty/mintty

which seems the be the "deadlock" issue you hinted at.
Can you provide some idea to work around this problem? Admittedly, I have no clue.

Regards,
Xavier

[Andy Koppe]

Me neither, I'm afraid, and I'm not sure whether it's the same issue I
mentioned, because what I'd seen was both processes waiting for output
operations to finish, i.e. marked with 'O' in the ps output. I'd
reported that to the Cygwin mailing list at http://cygwin.com/ml/cygwin/2012-10/msg00434.html.
You might want to do the same, whereby a small self-contained test
case (instead of patching mintty) would probably help.

Andy