[PATCH] D53000: [Support] exit with custom return code for SIGPIPE

Jonas Devlieghere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 18 14:50:39 PDT 2019


JDevlieghere added a comment.

In D53000#1431452 <https://reviews.llvm.org/D53000#1431452>, @jfb wrote:

> In D53000#1431436 <https://reviews.llvm.org/D53000#1431436>, @JDevlieghere wrote:
>
> > In D53000#1430211 <https://reviews.llvm.org/D53000#1430211>, @jfb wrote:
> >
> > > In D53000#1430182 <https://reviews.llvm.org/D53000#1430182>, @JDevlieghere wrote:
> > >
> > > > Hey Nick,
> > > >
> > > > This change is causing problems in LLDB. We want to ignore `SIGPIPE` and this appears to be making that impossible, which doesn't sound fair for something like libSupport. I'm not at all familiar with this code, but can we at least check if the signal is supposed to be ignored here?
> > >
> > >
> > > I think you'll want to set up something like `InterruptFunction`: by default we'll do what Nick added, but if you ask we can do something else for `SIGPIPE`.
> >
> >
> > Wouldn't that affect all signals? What about an atomic boolean to enable/disable this behavior? Like I said before, I personally don't think this it is expected from a library like Support to do this. It feels like this behavior should be opt-in.
>
>
> I think we want something like `InterruptFunction`, where for clang (not as a library) we'll call `abort`, and for you we'd do nothing. Which one is the default doesn't really matter to me, and maybe makes more sense to do nothing. I think this is better than just a boolean.


Oh yeah, that makes sense too.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53000/new/

https://reviews.llvm.org/D53000





More information about the llvm-commits mailing list