This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: issue with ServerSocket::accept


David Daney wrote:

Looks like we don't implement blocking I/O interruption with close(). I've set up a bug report to track this issue, with a self-contained test case:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

Does anyone know of a good way to implement this? Can select() do it?


I haven't gone through the exercise, but what does accept(2) do when close(2) is called on the socket from another thread?


Intuition tells me that something will happen on the thread that called accept(). Perhaps accept returns -1. If this is the case you could check to see if the socket was closed and throw the exception.



Yeah, based on my brief experimentation, it seems that at least on linux, neither select() or accept() will return when close() or shutdown() is called on the socket from another thread.

Well maybe accept doesn't return when the socket is closed. Perhaps each thread entering ServerSocket.accept() should put itself on a list of blocked acceptors. Then when close() is called each thread on the list is interrupted...


The threads would have to synchronize when adding themselves to the list. Are multiple threads allowed to call accept() on the same socket? If that is not valid, then the implementation ought to be pretty simple - we can just add a thread field to each socket. We just have to watch out for race conditions in the signaling mechanism.

Regards

Bryce.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]