Sophie Hu wrote: > I know that each time after port_getn() returns some events, the related > sockets have to be re-associated after the events are processed(read, write, > accept…). But since in my code, there are many places where events are > processed (read), in order not to miss any socket re-association, instead of > reassoicate them after the events are processed, I decided to reassoicate > them (the ones who have event fired last time) in front of port_getn(). I > think in this way, all sockets which just process events will be reassoicated > again (Note that I need to reassociate all of them unless they are closed). > No reassociate of these sockets will be missed. And even if some sockets are > closed, they just fail to re-associate, but they will not affect anything. > > However, I found some sockets can still be reassoicated after they are > closed, which finally caused some problems. what is wrong with my approach? > Or maybe I have to do reassicate one by one? > > Normally, the application should be aware of which are the valid socket file descriptors that are being polled on. Once a socket gets closed, that descriptor should be removed from the list of descriptors being polled on since the descriptor could get reused.
In your case, it appears that the descriptor was valid when it got re-associated. That can happen if the file descriptor got reused when say another socket or a file that is pollable got opened before the re-associate. Therefore at the time of re-associate, this file descriptor happens to be valid and the re-associate succeeds. Is this something that could happen in your program? Since port_associate() needs to be called one at a time on each of the descriptors, you should be able to determine which ones to re-associate. The user pointer argument that gets returned with the event, can be useful in doing that. -Prakash. > > This message posted from opensolaris.org > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
