issue with ServerSocket::accept

Bryce McKinlay mckinlay@redhat.com
Fri May 14 19:08:00 GMT 2004


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.


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /