[usocket-devel] Patch for backend/lispworks.lisp
Hi, usocket developer I think there's two bugs in usocket trunk's backend/lispworks.lisp 1. in function USOCKET-LISTEN, you should listen the stream of a usocket, not the socket fd itself: (defun usocket-listen (usocket) (if (stream-usocket-p usocket) (when (listen (socket-stream usocket)) usocket) (when (comm::socket-listen (socket usocket)) usocket))) 2. in function #-win32 WAIT-FOR-INPUT-INTERNAL, mapcar didn't have a :KEY keyword: #-win32 (defun wait-for-input-internal (sockets &key timeout) (with-mapped-conditions () ;; unfortunately, it's impossible to share code between ;; non-win32 and win32 platforms... ;; Can we have a sane -pref. complete [UDP!?]- API next time, please? (mapcar #'(lambda (x) (mp:notice-fd (os-socket-handle x))) sockets) (mp:process-wait-with-timeout "Waiting for a socket to become active" (truncate timeout) #'(lambda (socks) (some #'usocket-listen socks)) sockets) (mapcar #'(lambda (x) (mp:unnotice-fd (os-socket-handle x))) sockets) (remove nil (mapcar #'usocket-listen sockets)))) Hope them can be merged. Thanks. Chun Tian (binghe)
On Sat, Jun 14, 2008 at 8:23 AM, binghe Chun Tian <binghe.lisp@gmail.com> wrote:
Hi, usocket developer
Hi!
I think there's two bugs in usocket trunk's backend/lispworks.lisp
Thanks for the report!
1. in function USOCKET-LISTEN, you should listen the stream of a usocket, not the socket fd itself:
(defun usocket-listen (usocket) (if (stream-usocket-p usocket) (when (listen (socket-stream usocket)) usocket) (when (comm::socket-listen (socket usocket)) usocket)))
2. in function #-win32 WAIT-FOR-INPUT-INTERNAL, mapcar didn't have a :KEY keyword:
#-win32 (defun wait-for-input-internal (sockets &key timeout) (with-mapped-conditions () ;; unfortunately, it's impossible to share code between ;; non-win32 and win32 platforms... ;; Can we have a sane -pref. complete [UDP!?]- API next time, please? (mapcar #'(lambda (x) (mp:notice-fd (os-socket-handle x))) sockets) (mp:process-wait-with-timeout "Waiting for a socket to become active" (truncate timeout) #'(lambda (socks) (some #'usocket-listen socks)) sockets) (mapcar #'(lambda (x) (mp:unnotice-fd (os-socket-handle x))) sockets) (remove nil (mapcar #'usocket-listen sockets))))
Hope them can be merged. Thanks.
Absolutely, you're right on both accounts. However, if you don't mind, I'd rather replace the mapcar invocations with dolist forms: they're non-consing. Bye, Erik.
Hi, Erik
Absolutely, you're right on both accounts. However, if you don't mind, I'd rather replace the mapcar invocations with dolist forms: they're non-consing.
OK, and thanks for fast response. By the way, are you still interesting in my UDP patch? Some people hope my UDP work can be merged into USOCKET.
Bye,
Erik.
On Sat, Jun 14, 2008 at 2:48 PM, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:
Hi, Erik
Absolutely, you're right on both accounts. However, if you don't mind, I'd rather replace the mapcar invocations with dolist forms: they're non-consing.
OK, and thanks for fast response.
Committed to trunk just a few moments ago. If you have any further remarks, please don't hesitate to say so.
By the way, are you still interesting in my UDP patch? Some people hope my UDP work can be merged into USOCKET.
Absolutely, but I've gotten swamped by some other work lately, meaning I'm just now getting back to usocket and other projects. I'll try to work on it in the next weeks: there's also the wait-for-input branch (0.4.x) to work on and get into releasable state. There's a problem with that branch however: Hans Huebner said that the wai-for-input function consed too much for ITA to be usefull. Hans, if you're reading this, could you elaborate? Doug Crosher submitted ideas for other APIs which would cons less, however, do you have an analysis of what is wrong with the current API or code? Bye, Erik.
OK, and thanks for fast response.
Committed to trunk just a few moments ago. If you have any further remarks, please don't hesitate to say so.
Thanks.
By the way, are you still interesting in my UDP patch? Some people hope my UDP work can be merged into USOCKET.
Absolutely, but I've gotten swamped by some other work lately, meaning I'm just now getting back to usocket and other projects. I'll try to work on it in the next weeks: there's also the wait-for-input branch (0.4.x) to work on and get into releasable state.
Good. Actually, what I want is a portable UDP server, which can be used for this goal: http://groups.google.com/group/comp.lang.lisp/msg/782101b610d14e71 If you can make wait=for-input better, that's definitely helpful for everyone. Now I already have my UDP patch[1] to work on SBCL, CMUCL, Clozure CL and LispWorks. Base on this, I'm trying to use GBBopen's Portable_Threads package to implement a portable UDP server, I think to finish it I need less than one week. I hope all these work can be merged into USOCKET in the future, if you have time to review them:) [1] https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trun...
There's a problem with that branch however: Hans Huebner said that the wai-for-input function consed too much for ITA to be usefull.
Hans, if you're reading this, could you elaborate? Doug Crosher submitted ideas for other APIs which would cons less, however, do you have an analysis of what is wrong with the current API or code?
Bye,
Erik.
participants (4)
-
Chun Tian -
Chun Tian (binghe)
-
Erik Huelsmann -
Erik Huelsmann