[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