[ofa-general] SDP poll() behavior

[Chevalier, David (GE Healthcare)]

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