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:
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 certain
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 rec
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
