> Thanks Sayantan. Sure we have to guard against EAGAIN, the question is > how. Ideally I would like to avoid polling on the send call (or any > other call for matter). > > To give you background, in my application I run a central epoll-driven > event loop for CQ events, CM events, ... but also IO events from other > non-network devices. So it would be natural to also throw the RDM > endpoint in there and have the event loop tell me when I can send.
In most cases, waiting on the tx/rx CQ fds should work. It won't guarantee that send won't return EAGAIN after the thread wakes up, but the thread should wake up when send is available. Whether this is true during the connection setup period is something that I'd have to look at the implementation to tell. I don't know which fd the underlying CM events signal, and if we can map those to the CQ fd. But this seems like a reasonable request by the apps for dealing with EAGAIN without needing to spin. - Sean _______________________________________________ ofiwg mailing list [email protected] https://lists.openfabrics.org/mailman/listinfo/ofiwg
