On Tue, 11 Oct 2005, Sean Hefty wrote:
> James Lentini wrote: > > Our goal is to provide an interface with semantics similar to the sockets > > interface. A socket's listen function does not block (e.g. inet_listen). > > Since not blocking is what ULPs expect, kDAPL's listen function does not > > block. The same should be true of the CMA function. > > From what I can see, kDAPL connect and listen calls can block, as does > inet_listen. I'm referring to the thread blocking within the call, > specifically on a semaphore and memory allocation using GFP_KERNEL. I am not > referring to listen blocking until a connection request is received. I thought you meant blocking for a connection request to arrive. Your right the kDAPL and inet_listen functions can block for the reasons you list. I'm ok with rdma_listen() also blocking for these reasons. james _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general