<br><div class="gmail_quote">On Mon, Oct 31, 2011 at 11:05 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><div class="gmail_quote">On Mon, Oct 31, 2011 at 21:02, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


 A-MPI "replaces" each single Unix process with a collection of threads (that each behave like processes with regard to MPI) hence the users entry point cannot be called main() because main is called once by the OS when it starts up the Unix process. Thus the A-MPI mpi.h changes the users main() routine to a different name and the A-MPI startup system calls this new routine for each of these threads/pseudo-MPI processes.</blockquote>


</div><br></div><div>Okay, does signal handling still work alright?</div>
</blockquote></div><br>I'm quite sure it does not -- in fact, even any kind of non-automatic variables (global or static) will share the same memory between MPI "processes", last I looked. It's basically turning MPI processes into shared-memory threads, with private stacks, of course -- which can have lots of unintended side effects. Basically, you have to avoid any such variables and privatize them by having each thread allocate dynamic memory and use that. It's kinda easy enough to do for a small Fortran program with a few common blocks, but doing it for PETSc sounds like a major project to me.<br>

<br>I haven't looked at AMPI in a while, though, maybe things changed.<br><br>--Kai<br><br clear="all"><br>-- <br>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>

office: Morse Hall 245E<br>phone:  +1-603-862-2912<br>fax: +1-603-862-2771<br><br>