emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matthias Dahl
Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
Date: Mon, 20 Nov 2017 16:29:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Hello Paul...

On 19/11/17 08:07, Paul Eggert wrote:

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

Done already locally, will be in the revised patch.

> * 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....)

I believe Eli said he will take care of this one.

> * 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.

Thanks, didn't know about that one. Will do.

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

On my todo, will be on the new patch.

> * 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));

Actually, I already spotted this and corrected it locally. I would have
mentioned it in the revised patch. Thanks though for your keen eye. :-)

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

Not quite. The long comment explicitly explains why we can always do
the subtraction this way because we could end up in a situation were we
subtract a larger number from a smaller number, e.g. when the initial
value was close to the max and once data was read, we had a wrap around.

The assignment itself was another issue, that went unnoticed in the
first patch. ;-)

I'll update the patches tomorrow most likely and send them to the list
as I just didn't get around to it today.

Thanks again for all the great feedback.

So long,
Matthias

-- 
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]