[usocket-cvs] r667 - in usocket/branches/0.5.x: . backend

[ctian at common-lisp.net]

Author: ctian
Date: Mon Aug  8 07:20:23 2011
New Revision: 667

Log:
[SBCL] Fixed for "SBCL data flush problem", reported by Robert Brown and confirmed by Nikodemus Siivola.

Modified:
   usocket/branches/0.5.x/CHANGES
   usocket/branches/0.5.x/backend/sbcl.lisp

Modified: usocket/branches/0.5.x/CHANGES
==============================================================================
--- usocket/branches/0.5.x/CHANGES	Thu Jun 30 09:38:18 2011	(r666)
+++ usocket/branches/0.5.x/CHANGES	Mon Aug  8 07:20:23 2011	(r667)
@@ -3,6 +3,7 @@
 * Bugfix: [MCL] Fixed SOCKET-LISTEN on vector addresses like #(0 0 0 0)
 * Bugfix: [MCL] Fixed WAIT-FOR-INPUT on passive sockets (stream-server-usocket)
 * Bugfix: [LispWorks] Fixed using OPEN-UDP-SOCKET in delivered applications (thanks to Camille Troillard and Martin Simmons, this fix is from LispWorks-UDP project).
+* Bugfix: [SBCL] Fixed for "SBCL data flush problem", reported by Robert Brown and confirmed by Nikodemus Siivola.
 
 0.5.2:
 

Modified: usocket/branches/0.5.x/backend/sbcl.lisp
==============================================================================
--- usocket/branches/0.5.x/backend/sbcl.lisp	Thu Jun 30 09:38:18 2011	(r666)
+++ usocket/branches/0.5.x/backend/sbcl.lisp	Mon Aug  8 07:20:23 2011	(r667)
@@ -298,10 +298,24 @@
                 ;; Now that we're connected make the stream.
                 (setf (socket-stream usocket)
                       (sb-bsd-sockets:socket-make-stream socket
-                                                         :input t
-                                                         :output t
-                                                         :buffering :full
-                                                         :element-type element-type))))
+                        :input t :output t :buffering :full
+			:element-type element-type
+			;; Robert Brown <robert.brown at gmail.com> said on Aug 4, 2011:
+			;; ... This means that SBCL streams created by usocket have a true
+			;; serve-events property.  When writing large amounts of data to several
+			;; streams, the kernel will eventually stop accepting data from SBCL.
+			;; When this happens, SBCL either waits for I/O to be possible on
+			;; the file descriptor it's writing to or queues the data to be flushed later.
+			;; Because usocket streams specify serve-events as true, SBCL
+			;; always queues.  Instead, it should wait for I/O to be available and
+			;; write the remaining data to the socket.  That's what serve-events
+			;; equal to NIL gets you.
+			;;
+			;; Nikodemus Siivola <nikodemus at random-state.net> said on Aug 8, 2011:
+			;; It's set to T for purely historical reasons, and will soon change to
+			;; NIL in SBCL. (The docstring has warned of T being a temporary default
+			;; for as long as the :SERVE-EVENTS keyword argument has existed.)
+			:serve-events nil))))
              (:datagram
               (when (or local-host local-port)
                 (sb-bsd-sockets:socket-bind socket