ServerSocket.accept()/scheduler bug (Kaffe 0.91 BSDI 3.1)

[David Caldwell]

______________________________ Forward Header __________________________________
Subject: ServerSocket.accept()/scheduler bug (Kaffe 0.91 BSDI 3.1)
Author:  David Caldwell at TRANS_PO
Date:    2/5/98 8:48 AM


     Hello all.
     
     I tried to subscribe to the mailing list by sending a "subscribe" 
     message to kaffe-request@tjwassoc.demon.co.uk, but I haven't heard 
     back.  This message is being sent to kaffe@tjwassoc.demon.co.uk.
     
     PROBLEM
     
     After long examination, I believe I've found a Kaffe bug.  The method 
     accept() of java.net.ServerSocket not only blocks when it is called, 
     it will:
     
        (a)     ignore the SoTimeout parameter,
     
        (b)     never relinquish the CPU.
     
     My program runs fine on Sun's Windows 95 implementation, which has a 
     pre-emptive scheduler.  Though I have not been able to test the 
     program with a non-preemptive scheduler, I've done enough testing to 
     decide that it -should- work on a non-pre-emptive scheduler, also.
     
     FAILED WORKAROUNDS
     
     I've tried a number of workarounds -- killing the thread, lowering its 
     priority, etc.  You can't kill the thread because it's blocking and 
     won't give any other thread the CPU for even one instruction.  No 
     matter how low the thread's priority is, if it gets to the accept() 
     call, it will hang there forever -- or until another socket connection 
     is received.
     
     POTENTIAL WORKAROUND
     
     Because it will release when another connection is received, I could 
     construct a workaround -if- there was a ServerSocket method which told 
     whether there were any connections backlogged (analogous to the 
     ready() method for InputStreams).  But I can't find any such method -- 
     so that's a Java question.
     
     ACTUAL (BUT UNTESTED, NATCH) WORKAROUND
     
     The other workaround (which I haven't tried -- but am counting on) is 
     to start a SECOND virtual machine and have it (more or less) 
     continually request socket connections with the first VM; then send 
     something through the socket verifying that it's a "fake" connection, 
     thus allowing the first VM to unblock and proceed.  Inelegant, but if 
     you're desperate, it would probably work.  I'll follow up.
     
     NOTES
     
     I can't actually look at the source code because I don't control my 
     own Kaffe distribution (my web hoster does).  Unless I want to 
     download it locally, which I don't, at least for the moment.  
     
     REPLY TO
     
     Also, I'm not sure that I'm actually subscribed to the mailing list 
     (haven't received confirmation) so any replies should go to 
     inonit@inonit.com.
     
     WHAT I'M LOOKING FOR
     
        (a)     Workaround, if possible.
     
        (b)     Less important would be a fix to the underlying problem.
     
     -- David.