Hi Luiz, >> Luckily you asked, because I found out that actually the patch didn't >> wait for the disconnection response for any case. It does delay the >> disconnection of the ctrl channel slightly though, but that doesn't >> guarantee a proper order of disconnection. Therefore, as of now, this >> patch is not fixing anything. >> >> Digging more into this matter, I found out by removing this condition >> (sk->sk_shutdown == SHUTDOWN_MASK) in [1], it makes intr_watch_cb() >> called after truly receiving the interrupt disconnection response. >> However, I haven't checked whether removal of such condition will >> break other things. >> Do you have any suggestions? > > I see, we shutdown the socket immediately since the socket API itself > don't seem to have a concept of disconnect syscall not sure if other > values could be passed to shutdown second parameter to indicate we > want to actually wait it to be disconnected. in a blocking synchronous system call world we have SO_LINGER for that. In the world of asynchronous IO handling (what we do), we need to check what is the right way of handling this. Regards Marcel
