"Jerry James" <james@xemacs.org> writes:

> On Jan 3, 2008 1:56 AM, Michael Sperber <sperber@deinprogramm.de> wrote:
>> Hi Jerry,
>>
>> this was still sitting around in my e-mail.  What ever happened with
>> this patch?  (It doesn't seem to've gotten applied.)
>
> Wow, you're really straining my memory here. :-)  The fact is that I
> do not have this email in my personal archive, and as far as I know
> there is still no public archive that goes back that far, right?  I
> seem to recall that we solved the problem in another way, and that I
> deleted the emails about this patch because they became irrelevant.
> Have you had any problems with losing data that was supposed to be
> sent to another process?

Yes - larger chunks don't seem to get there a lot of the time.  I
haven't investigated yet in detail - there's other stuff in the queue
before it, and going through old e-mail is one of them.

On Jan 3, 2008 10:32 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> I think one or both of these patches superceded that one.
>
> 2004-11-12  Jerry James  <james@xemacs.org>
>
>         * lstream.c (Lstream_really_write): Don't call the flusher if the
>         writer returned an error.
>
> 2004-03-08  Lutz Euler  <lutz.euler@freenet.de>
>
>         * lstream.c (Lstream_pseudo_close): Fix test for LSTREAM_FL_IS_OPEN.

Those are too early.  The date on the patch Mike is asking about is
2004-11-29, after both of these were applied.  It's starting to come
back to me now.  We decided that the problem was only happening on
Unix systems, and my patch was causing problems on non-Unix systems.
If I remember correctly, the final fix was this one:

2005-02-03  David Evers  <extsw@appliedgenerics.com>

        * process-unix.c (unix_send_process): Flush the last chunk, even
        when the pipe is blocked.

Hi Jerry, 

this was still sitting around in my e-mail.  What ever happened with
this patch?  (It doesn't seem to've gotten applied.)

Jerry James <james@xemacs.org> writes:

> Adrian Aichner <adrian@xemacs.org> wrote:
>> Since I reverted my own patch to close handles, and built with Ben's
>> megapatch implementing a corrected version thereof, I have not seen
>> these uninterruptible hangs.  I've been using XEmacs every day and
>> kept it running for many days so I should have ween them.
>>
>> Thanks Ben!
>
> [snip]
>
>> It probably was not your patch after all, as stated above.
>
> Well ... great!  Would you mind trying my patch again, then?  For
> convenience, here it is:
>
> Index: lstream.c
> ===================================================================
> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/lstream.c,v
> retrieving revision 1.31
> diff -d -u -r1.31 lstream.c
> --- lstream.c	2004/11/12 17:16:30	1.31
> +++ lstream.c	2004/11/29 04:42:28
> @@ -778,8 +778,21 @@
>  static int
>  Lstream_pseudo_close (Lstream *lstr)
>  {
> +  int flush_rc;
> +
>    if (! (lstr->flags & LSTREAM_FL_IS_OPEN))
>      Lstream_internal_error ("lstream is not open", lstr);
> +
> +  /* Flush all the data in the buffer before closing.
> +     May require multiple passes thru Lstream_flush_out().
> +     This loop (instead of just calling Lstream_flush_out(),
> +     fixes a problem where we sometimes lose data sent to
> +     a process.
> +  */
> +
> +  do {
> +    flush_rc = Lstream_flush_out(lstr);
> +  } while (lstr->out_buffer_ind > 0 && flush_rc >= 0);
>  
>    /* don't check errors here -- best not to risk file descriptor loss */
>    return Lstream_flush (lstr);
>
> If the hangs return, then we can try the approach of figuring out what
> data is getting lost here and where it was supposed to go.
>
> Thanks,
> -- 
> Jerry James
> http://www.ittc.ku.edu/~james/
>