 |
 |
Hi Brian, Never mind.... I see that the cmsd uses the mechanism so that really means that the cmsd is stopping. No need to verify whethe somebondy else issuing the sigstop. It should be safe to comment out the sigstop/sigcont lines. I will remove he code. Andy On Tue, 23 Aug 2011, Brian Bockelman wrote: > > On Aug 23, 2011, at 5:07 PM, Andrew Hanushevsky wrote: > >> On Tue, 23 Aug 2011, Brian Bockelman wrote: >> >>> I'm not quite following what the issue is from the in-code comments, but isn't this what SO_LINGER (POSIX-compliant) is for? >> No, that isn't (at least wasn't) a solution for the problem. If there >> was an operation in progress when you closed the socket, the close would not be reflected to the person who initiated the operation (unlike all other operating systems) until some activity occurred that caused the kernel to re-inspect the operation (e,g, signal). So, the initiating thread would simply hang. That might no longer be the case in current versions of Linux. But in the day it was a huge hassle since async close() operations occur relatively frequently. Anyway, the implementation of SO_LINGER varies from OS to OS and even in versions of an OS. That's what I found when dealing with this pronlem and that's what people say out there. >> > > Hm. It should be easy to construct a test case, right? With two threads: > 1) Thread 1 creates a socket pair, and writes to the write-end until it blocks. > 2) Thread 2 waits for some reasonable amount of time, then closes the socket. > 3) If Linux still shows this behavior, Thread 1 should hang... > > Brian