<div dir="ltr"><div>Hi Junchao, </div><div><br></div><div>Thanks for pointing me to the MR, I will follow the discussion there from now on.</div><div><br></div><div>--</div><div>John</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 10:58 AM Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com">junchao.zhang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>John,</div><div>  I had an MR at <a href="https://gitlab.com/petsc/petsc/-/merge_requests/2745" target="_blank">https://gitlab.com/petsc/petsc/-/merge_requests/2745</a>. Currently, we could not agree on a solution. The concern is if we do _Exit() instead of MPI_Abort() in signal handler, then some MPI (batch system) might not be able to kill all MPI processes.</div><div>  I prefer _Exit(), because it can solve the problem you reported (actually happened).</div><div><br clear="all"><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 10:22 AM John Peterson <<a href="mailto:jwpeterson@gmail.com" target="_blank">jwpeterson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Junchao,</div><div><br></div><div>I was just wondering if there was any update on this? I saw your question on the discuss@mpich thread, but I gather you have not received a response yet.</div><div><br></div><div>--</div><div>John</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 21, 2020 at 10:09 PM Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>  I don't see problems calling _exit in PetscSignalHandlerDefault. Let me try it first.</div><div><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 21, 2020 at 3:17 PM John Peterson <<a href="mailto:jwpeterson@gmail.com" target="_blank">jwpeterson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I started a thread on <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a> regarding some hanging canceled jobs that we were seeing:</div><div><br></div><div><a href="https://lists.mpich.org/pipermail/discuss/2020-April/005910.html" target="_blank">https://lists.mpich.org/pipermail/discuss/2020-April/005910.html</a><br clear="all"><div><br></div><div>It turns out that there are some fairly strict rules about what types of functions (asynchronous-safe only) can be called from signal handlers, and MPI_Abort(), at least the mpich implementation of it, apparently does not fall into that category. I wonder if you have any comments on this. One possibility might be might be to just call "_exit" from PetscSignalHandlerDefault rather than PETSCABORT, not sure what other issues that would cause, however.</div><div><br></div>Thanks, <br><div dir="ltr">John</div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div></div>
</blockquote></div>
</blockquote></div><br></div>