On May 14, 2013, at 3:02 PM, Ralph Castain <r...@open-mpi.org> wrote:
> > On May 14, 2013, at 12:56 PM, Damien Kick <dk...@shoretel.com> wrote: > >> >> On May 14, 2013, at 1:46 PM, Ralph Castain <r...@open-mpi.org> >> wrote: >> >>> Problem is that comm_accept isn't thread safe in 1.6 series - we have a >>> devel branch that might solve it, but is still under evaluation >> >> So then probably the only way to implement an MPI server which handles >> multiple concurrent clients with Open MPI 1.6.4 is to use multiple processes >> to handle each client connection, yes? > > Or introduce your own thread protection around the comm_accept call Hmm … but won't that cause other problems when the call to MPI_Comm_accept blocks while we're still holding the mutex? There doesn't seem to be an option to MPI_Comm_accept to timeout nor does there seem to be a variant of MPI_Probe to allow for a non-blocking accept. Am I missing something? One more question, too (and thanks for all your help), I don't see anything in the man page for MPI_Comm_accept which mentions iterations with signals. Is there a reliable behavior in this context, i.e. return an error from MPI_Comm_accept and set errno to EINTR? Would the C++ binding throw an exception? <pause/> I suppose that one could use MPI_Comm_join to have "normal socket code" handle connections without worrying about blocking the rest of MPI and then only introduce a mutex when we know we're reading to MPI_Comm_join. ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.
