I agree that SDP should have the same behavior as TCP in this situation. Bug 1020 has been opened so we can track the issue.
Thanks David! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chevalier, David (GE Healthcare) Sent: Monday, April 28, 2008 10:14 AM To: [email protected] Subject: [ofa-general] SDP poll() behavior Hi SDP developers, I've noticed apparent difference between SDP and TCP/IP handling of certain scenario (OFED 1.3), not necessarily a bug, but wondering if it might be better to behave more like TCP/IP in this case: receiver and sender use non-blocking sockets (SDP) and monitor through poll() sender writes a known quantity of data through many calls to write(), then closes its side of socket. receiver polls socket, and reads the data through many calls to read(), then closes its socket. receiver is monitoring poll() revents for POLLERR, POLLHUP and POLLIN On the receiver's last expected pass through the poll() loop to read() the last remaining data, I'll often get revents of {POLLERR|POLLHUP|POLLIN}, likely due to sender closing its socket after last write(). If my poll() handling loop goes in this order: check/handle POLLERR check/handle POLLHUP check/handle POLLIN then it fails, because I don't expect to be able to read() data when poll() return POLLERR or POLLHUP. If I change the order and handle POLLIN first, then read() works and gets the last data. I've never encountered this in TCP/IP - that is to say, for TCP/IP I first receive a clean POLLIN from poll(), then the next poll()(after I read() the data) returns POLLHUP (without the POLLERR). If I get POLLERR from poll(), I'd expect subsequent call to read() to return an error, not valid data... While this is probably an "implementation defined" behavior, it seems like a good idea to try to behave the same as the TCP/IP sockets that SDP aims to replace... Regards, Dave _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
