Thank you, Brice,
you confirmed what I worried about already. So, I will either have a
significant overhead from thread context switches or a good amount of my
cpu power will go into polling. This is really bad. If there is no
interrupt based mechanism such as select(), which can wait for a number
Usually, when you want to listen to two kinds of event, you use
poll/select on Unix (or epoll on Linux). This strategy doesn't work for
MPI events because MPI doesn't provide a Unix file descriptor to pass to
poll/select/epoll. One work-around is to have one thread listen to MPI
events. When it
I suspect nobody is answering because the question makes no sense to us. You
are implying that the TCP socket is outside of MPI since it isn’t tied to a
communicator. If you want to setup a non-MPI communication path between two
procs and monitor it separate from the MPI library, you can
Dear all,
I have not yet found a solution for waiting for an event (incoming message)
to occur either on a TCP socket or on a MPI communicator. I wish I could
receive some comments from you MPI experts.
If my question was unclear, I found the same problem described on the MPICH
list two years ago:
