Print

Print

Well, I respectfully disagree :) From the client perspective three things can happen after XrdNetConnect::Connect is called:

  1. Immediate error (errno != 0 && errno != EINPROGRESS) - client runs/schedules recovery
  2. Async operation has been scheduled and the outcome is not known at the point (errno == EINPROGRESS) - client declares a temporary success, and expects to receive READYTOWRITE should the status change, in this case the possible error is handled in the callback, if there is no error it proceeds with the handshake
  3. Connect succeeded immediately - client treats it as the case above. This is because, if you think about it, it really is the same. Since the socket is new and nothing has been written to it yet, it should become writable at some point, and since the poller is supposed to be level-triggered it should send READYTOWRITE notifications as long as the socket remains writable. So, the client should receive the callback, and when it does, it again invokes getsockopt SOL_SOCKET SO_ERROR which returns success (it's an overhead to check for the same error twice, but performance-wise it's negligible), and then in proceeds with the handshake. The only difference is that the success is not declared immediately, but in the callback instead.

So there is indeed a logic error. It is in the poller.

—
Reply to this email directly or view it on GitHub.


Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1