On May 14, 2013, at 3:02 PM, Ralph Castain <rhc_at_[hidden]>
> On May 14, 2013, at 12:56 PM, Damien Kick <dkick_at_[hidden]> wrote:
>> On May 14, 2013, at 1:46 PM, Ralph Castain <rhc_at_[hidden]>
>>> 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
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.