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 rec
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
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:
Dear all,
I am looking for a solution to receive messages either via MPI or via a TCP
socket, whichever arrives next.
Using the select() method as described for example at
http://developerweb.net/viewtopic.php?id=2933, I can have my code wait
until any of a given set of TCP sockets receives some d
