Hi Chun,
Thanks for looking into this. I've just pulled the most recent codes from github and have had a little play with them. I now get an error signalled on the socket-receive when I expect an error (rather than a simple -1 count as before). This is good.
However, I am still seeing the socket-state behaviour I described before, along with a new bug that has probably been introduced by the recent changes.
Consider the following simple function which listens for UDP port 8001 for up to 4 iterations:
(defun usocket-test ()
(let ((s (usocket:socket-connect nil nil
:protocol :datagram
:element-type '(unsigned-byte 8)
:local-port 8001)))
(unwind-protect
(do ((i 0 (1+ i))
(buffer (make-array 1024 :element-type '(unsigned-byte 8) :initial-element 0))
(done nil))
((or done (= i 4))
nil)
(when (usocket:wait-for-input s :ready-only t :timeout 10)
(format t "~D state ~S~%" i (usocket::state s))
(handler-case
(multiple-value-bind (buffer count remote-host remote-port)
(usocket:socket-receive s buffer 1024)
(handler-case
(usocket:socket-send s (subseq buffer 0 count)
:host remote-host
:port remote-port)
(error (c)
(format t "socket-send error: ~A~%" c))))
(error (c)
(format t "socket-receive error: ~A~%" c)))))
(usocket:socket-close s))))
after calling this from your repl, from another process send a UDP packet to port 8001 to get things going. I get the following output:
0 state :READ
socket-send error: #<STANDARD-GENERIC-FUNCTION USOCKET:SOCKET-SEND 21CADCFA> is called with unpaired keyword in (2130706433 :PORT 58279).
1 state :READ
socket-receive error: MAKE-INSTANCE is called with keyword :SOCKET among the arguments (USOCKET:NS-TRY-AGAIN-CONDITION :SOCKET 2604) which is not one of (:HOST-OR-IP).
2 state :READ
socket-receive error: MAKE-INSTANCE is called with keyword :SOCKET among the arguments (USOCKET:NS-TRY-AGAIN-CONDITION :SOCKET 2604) which is not one of (:HOST-OR-IP).
3 state :READ
socket-receive error: MAKE-INSTANCE is called with keyword :SOCKET among the arguments (USOCKET:NS-TRY-AGAIN-CONDITION :SOCKET 2604) which is not one of (:HOST-OR-IP).
NIL
My observations:
1. The initial socket-receive succeeds (as expected).
2. The initial socket-send fails with an error I've not seen before and can't diagnose...
3. Subsequent calls to wait-for-input return immediately because the socket is still in a :READ state, even though I already successfully called socket-receive in the first iteration.
4. Subsequent calls to socket-receive now fail with a different error I can't diagnose.
If I didn't have the max iteration cap, this would spin using 100% of a CPU core and adding around 2MB to the heap per second (on my machine), maxing out the 1GB personal edition heap limit in a short space of time. So I think it's a pretty serious issue. I mainly use SBCL, I use LispWorks occasionally to make sure my codes work on at least 1 other implementation, so I'm not exactly a LispWorks expert.
If you want any more explanations, clarifications or examples I'll be happy to do my best to help.
As before, I'm using LispWorks personal edition 6.1.1 on Windows 8.1.
Frank.