Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Paul Eggert <eggert@cs.ucla.edu>]

Matthias Dahl wrote:
> If you treat the process as a shared resource, it is your sole
> responsibility to take care of proper management and synchronization of
> the process as well.

OK, but this is all news to me. Shouldn't this be documented? As things stand, 
it is not obvious.

So, getting back to the patch proposed in 
<https://lists.gnu.org/r/emacs-devel/2017-11/msg00193.html>, this discussion 
convinced me that the approach will work well enough. I have the following 
suggestions for improvement:

* Fix the bug with carryover that I mentioned in 
<https://lists.gnu.org/r/emacs-devel/2017-11/msg00283.html>.

* Document in the Elisp manual that filters and timers are supposed to do 
"proper management and synchronization", and be clear about how this constrains 
filters and timers. (This is probably the hardest part of the fix....)

* Change the type of infd_num_bytes_read from EMACS_UINT to uintmax_t. This will 
provide an extra margin of safety on some platforms. infd_num_bytes_read has 
nothing to do with Emacs integers, and wider counts are safer.

* Document in its comment that infd_num_bytes_read is actually the count modulo 
UINTMAX_MAX + 1.

* When assigning to got_some_output, ceiling it at INT_MAX to avoid overflow 
problems. Something like the following, say:

    got_some_output = min (INT_MAX, (wait_proc->infd_num_bytes_read
                                     - initial_wait_proc_num_bytes_read));

This removes the need for that long comment about overflow, since this 
assignment cannot overflow.

Thanks.