[PATCH 1 of 2 stable] worker: do not suppress EINTR

[Raphaël Gomès]

Before I review these (and your previous series), is there a reason why 
you use the ML instead of Heptapod (as per 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2022-May/148466.html 
) considering you're already using it for your pre-submission CI?

On 5/25/22 02:30, Manuel Jacob wrote:
> # HG changeset patch
> # User Manuel Jacob <me at manueljacob.de>
> # Date 1653433864 -7200
> #      Wed May 25 01:11:04 2022 +0200
> # Branch stable
> # Node ID d058898bdd462b03c5bff38ad40d1f855ea51c23
> # Parent  477b5145e1a02715f846ce017b460858a58e03b1
> # EXP-Topic worker-pickle-load-EINTR
> worker: do not suppress EINTR
>
> Before this change, when IOError with errno EINTR was raised during
> pickle.load(), the error was suppressed and loading from other file descriptors
> was continued.
>
> On Python 3, system calls failing with EINTR are retried (PEP 475). Therefore,
> the removal of this code should not make any difference.
>
> On Python 2, this is not generally the case. CPickle has no handling of EINTR.
> In one place it misinterprets it as EOF. In another place, it will raise
> IOError. However, this could happen in the middle of the stream. In this case,
> if pickle tries to load from the stream later, it will behave wrongly (usually
> it will raise an error, but loading of incorrect data or interpreter crashes
> are thinkable).
>
> diff --git a/mercurial/worker.py b/mercurial/worker.py
> --- a/mercurial/worker.py
> +++ b/mercurial/worker.py
> @@ -301,10 +301,6 @@
>                       selector.unregister(key.fileobj)
>                       key.fileobj.close()
>                       openpipes -= 1
> -                except IOError as e:
> -                    if e.errno == errno.EINTR:
> -                        continue
> -                    raise
>       except:  # re-raises
>           killworkers()
>           cleanup()
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel