From binghe.lisp at gmail.com Sun Sep 7 11:09:40 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun Sep 7 11:09:58 2008 Subject: [usocket-devel] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT Message-ID: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> Hi, usocket Just found a bug on 0.4.x branch, on LispWorks (non-win32 version). The WAIT-FOR-INPUT-INTERNAL function has a TRUNCATE operation on TIMEOUT: (defun wait-for-input-internal (wait-list &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? (dolist (x (wait-list-waiters wait-list)) (mp:notice-fd (os-socket-handle x))) (mp:process-wait-with-timeout "Waiting for a socket to become active" (truncate timeout) ;; IT'S HERE!!!!!!!!!!!!!!!!!!!!!!!!! #'(lambda (socks) (let (rv) (dolist (x socks rv) (when (usocket-listen x) (setf (state x) :READ rv t))))) (wait-list-waiters wait-list)) (dolist (x (wait-list-waiters wait-list)) (mp:unnotice-fd (os-socket-handle x))) wait-list))) So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT keyword supply, (TRUNCATE NIL) will be called, and error happens. How to fix this issue to make sure I can just wait "infinitely" on a usocket? Regards, Chun Tian (binghe) From hans at huebner.org Sun Sep 7 11:33:49 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun Sep 7 11:34:02 2008 Subject: [usocket-devel] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT In-Reply-To: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> References: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> Message-ID: On Sun, Sep 7, 2008 at 17:09, Chun Tian (binghe) wrote: > So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT keyword > supply, (TRUNCATE NIL) will be called, and error happens. How to fix this > issue to make sure I can just wait "infinitely" on a usocket? Not having tried it, but (and timeout (truncate timeout)) should do, no? -Hans From binghe.lisp at gmail.com Sun Sep 7 11:46:55 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun Sep 7 11:47:23 2008 Subject: [usocket-devel] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT In-Reply-To: References: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> Message-ID: <91FB7110-B184-459A-8069-AAA86B394908@gmail.com> ÔÚ 2008-9-7£¬ÏÂÎç11:33£¬ Hans H¨¹bner дµÀ£º > On Sun, Sep 7, 2008 at 17:09, Chun Tian (binghe) > wrote: > >> So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT >> keyword >> supply, (TRUNCATE NIL) will be called, and error happens. How to >> fix this >> issue to make sure I can just wait "infinitely" on a usocket? > > Not having tried it, but (and timeout (truncate timeout)) should do, > no? I don't think so. MP:PROCESS-WAIT-WITH-TIMEOUT must be called with a TIMEOUT parameter as integer (in seconds). If TIMEOUT is NIL, WAIT-FOR-INPUT-INTERNAL maybe should turn to call MP:PROCESS-WAIT instead of MP:PROCESS-WAIT- WITH-TIMEOUT: http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-445.htm I made a patch based on above idea, as in attach, it works under simple test. Regards, Chun Tian (binghe) -------------- next part -------------- A non-text attachment was scrubbed... Name: usocket-wfl-lispworks.diff Type: application/octet-stream Size: 1535 bytes Desc: not available Url : http://common-lisp.net/pipermail/usocket-devel/attachments/20080907/fffa6558/usocket-wfl-lispworks.obj -------------- next part -------------- From ehuels at gmail.com Thu Sep 18 11:45:32 2008 From: ehuels at gmail.com (Erik Huelsmann) Date: Thu Sep 18 11:45:38 2008 Subject: [usocket-devel] Re: usocket-devel post from larsnostdal@gmail.com requires approval In-Reply-To: References: Message-ID: Hi Lars! Thanks for the report. Sorry for the delay; I finally committed your fix. I've applied a similar fix to SOCKET-LISTEN. Bye, Erik. On Tue, Aug 26, 2008 at 2:10 PM, wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: usocket-devel@common-lisp.net > From: larsnostdal@gmail.com > Subject: [Fwd: Don't want FD leaks (patch)] > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > http://common-lisp.net/cgi-bin/mailman/admindb/usocket-devel > > to approve or deny the request. > > > ---------- Forwarded message ---------- > From: Lars Rune N?stdal > To: usocket-devel@common-lisp.net > Date: Tue, 26 Aug 2008 14:11:33 +0200 > Subject: [Fwd: Don't want FD leaks (patch)] > > > > ---------- Forwarded message ---------- > From: Lars Rune N?stdal > To: > Date: Tue, 26 Aug 2008 14:04:09 +0200 > Subject: Don't want FD leaks (patch) > Hi, > Noticed that FDs leak in some cases. Quick test and a patch: > > (defun test () > (loop > (handler-case > (let ((socket (usocket:socket-connect "aoeuaoeu.com" 80))) > (princ socket) (terpri)) > (t (c) > (format t "do i leak? ~A~%" c))))) > > > I use lsof to test for leaks while this is running: > lnostdal@blackbox:~/programming/lisp/usocket$ lsof -a -p 25803 | nl > > Here is the patch; not tested much but seems to work for me: > > > lnostdal@blackbox:~/programming/lisp/usocket$ svn diff > Index: backend/sbcl.lisp > =================================================================== > --- backend/sbcl.lisp (revision 423) > +++ backend/sbcl.lisp (working copy) > @@ -213,27 +213,32 @@ > (not (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay))) > (unsupported 'nodelay 'socket-connect)) > > - (let* ((socket (make-instance 'sb-bsd-sockets:inet-socket > - :type :stream :protocol :tcp)) > - (stream (sb-bsd-sockets:socket-make-stream socket > - :input t > - :output t > - :buffering :full > - :element-type element-type)) > - ;;###FIXME: The above line probably needs an :external-format > - (usocket (make-stream-socket :stream stream :socket socket)) > - (ip (host-to-vector-quad host))) > - (when (and nodelay-specified > - (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay)) > - (setf (sb-bsd-sockets:sockopt-tcp-nodelay socket) nodelay)) > - (when (or local-host local-port) > - (sb-bsd-sockets:socket-bind socket > - (host-to-vector-quad > - (or local-host *wildcard-host*)) > - (or local-port *auto-port*))) > - (with-mapped-conditions (usocket) > - (sb-bsd-sockets:socket-connect socket ip port)) > - usocket)) > + (let ((socket (make-instance 'sb-bsd-sockets:inet-socket > + :type :stream :protocol :tcp))) > + (handler-case > + (let* ((stream (sb-bsd-sockets:socket-make-stream socket > + :input t > + :output t > + :buffering :full > + :element-type element-type)) > + ;;###FIXME: The above line probably needs an :external-format > + (usocket (make-stream-socket :stream stream :socket socket)) > + (ip (host-to-vector-quad host))) > + (when (and nodelay-specified > + (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay)) > + (setf (sb-bsd-sockets:sockopt-tcp-nodelay socket) nodelay)) > + (when (or local-host local-port) > + (sb-bsd-sockets:socket-bind socket > + (host-to-vector-quad > + (or local-host *wildcard-host*)) > + (or local-port *auto-port*))) > + (with-mapped-conditions (usocket) > + (sb-bsd-sockets:socket-connect socket ip port)) > + usocket) > + (t (c) > + ;; Make sure we don't leak filedescriptors. > + (sb-bsd-sockets:socket-close socket) > + (error c))))) > > (defun socket-listen (host port > &key reuseaddress > > > > -- > Lars Rune N?stdal || AJAX/Comet GUI type stuff for Common Lisp > http://nostdal.org/ || http://groups.google.com/group/symbolicweb > > > ---------- Forwarded message ---------- > From: usocket-devel-request@common-lisp.net > To: > Date: > Subject: confirm c133299de2b1ebf623d1c8e5ce04db0e85ab23b7 > If you reply to this message, keeping the Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply. > From xach at xach.com Sat Sep 27 17:12:53 2008 From: xach at xach.com (Zach Beane) Date: Sat Sep 27 17:13:05 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 Message-ID: <20080927211253.GI7270@xach.com> When compiling usocket 0.3.7 on CLISP 2.46, I get this error: ;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist Any ideas? Zach From sky at viridian-project.de Sat Sep 27 18:30:53 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sat Sep 27 18:31:04 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <20080927211253.GI7270@xach.com> References: <20080927211253.GI7270@xach.com> Message-ID: <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> > When compiling usocket 0.3.7 on CLISP 2.46, I get this error: > > ;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... > ** - Continuable Error > FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not > exist > > Any ideas? Does it work if you put this: (ffi:default-foreign-language :stdc) (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is into your ~/.clisprc ? Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From sky at viridian-project.de Sat Sep 27 18:37:37 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sat Sep 27 18:37:39 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> Message-ID: <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> > Does it work if you put this: > > (ffi:default-foreign-language :stdc) > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is > > into your ~/.clisprc ? If this doesn't help, try adding #+unix (:library "libc.so.6") ;; or darwin if you need it in backend/clisp.lisp, right below: (FFI:DEF-CALL-OUT get-host-name-internal (:name "gethostname") (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) :OUT :ALLOCA) (len ffi:int)) #+win32 (:library "WS2_32") -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From xach at xach.com Sat Sep 27 19:54:51 2008 From: xach at xach.com (Zach Beane) Date: Sat Sep 27 19:54:58 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> Message-ID: <20080927235451.GJ7270@xach.com> On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote: > > > Does it work if you put this: > > > > (ffi:default-foreign-language :stdc) > > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is > > > > into your ~/.clisprc ? > > If this doesn't help, try adding > > #+unix (:library "libc.so.6") ;; or darwin if you need it > > in backend/clisp.lisp, right below: > > (FFI:DEF-CALL-OUT get-host-name-internal > (:name "gethostname") > (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) > :OUT :ALLOCA) > (len ffi:int)) > #+win32 (:library "WS2_32") I used #+macos (:library "libc.dylib") and it did the trick, thanks. I think a similar trick may be needed on non-Mac Unixes. Zach From binghe.lisp at gmail.com Sun Sep 28 02:51:29 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun Sep 28 02:51:46 2008 Subject: [usocket-devel] What if a usocket instance be garbage collected? Message-ID: <8442E1E3-5C39-47A7-81A3-E3FBBF177805@gmail.com> Hi, usocket devel If a usocket instance has been garbage collected (or just cannot refer to it, i. e. lost it by set the variable to new value), does anyone (either usocket or CL platform) will consider closing the correspond socket fd automatically? I know at least one CL platform, LispWorks, has some related API (HCL:ADD-SPECIAL-FREE-ACTION) [1], and I want to use it in my UDP applications. Just don't know if this will be a common feature to be considered by usocket itself. Any opinions? --binghe [1] http://www.lispworks.com/documentation/lw51/LWUG/html/lwuser-149.htm#pgfId-890008 From ehuels at gmail.com Mon Sep 29 15:52:21 2008 From: ehuels at gmail.com (Erik Huelsmann) Date: Mon Sep 29 15:55:33 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <20080927235451.GJ7270@xach.com> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> Message-ID: On Sun, Sep 28, 2008 at 1:54 AM, Zach Beane wrote: > On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote: >> >> > Does it work if you put this: >> > >> > (ffi:default-foreign-language :stdc) >> > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is >> > >> > into your ~/.clisprc ? >> >> If this doesn't help, try adding >> >> #+unix (:library "libc.so.6") ;; or darwin if you need it >> >> in backend/clisp.lisp, right below: >> >> (FFI:DEF-CALL-OUT get-host-name-internal >> (:name "gethostname") >> (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) >> :OUT :ALLOCA) >> (len ffi:int)) >> #+win32 (:library "WS2_32") > > I used #+macos (:library "libc.dylib") and it did the trick, thanks. I > think a similar trick may be needed on non-Mac Unixes. The reason it's not there yet is that I'm unaware of a good way to detect which libc version is installed on a system. Or would it always be libc.so.6? Bye, Erik. From sky at viridian-project.de Tue Sep 30 04:22:46 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue Sep 30 04:23:00 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> Message-ID: <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> > The reason it's not there yet is that I'm unaware of a good way to > detect which libc version is installed on a system. Or would it always > be libc.so.6? I suppose libc5 is outdated enough to forget about it and a libc7 is still far away. :) So the libc6 statement would work for 99% of UNIX users whereas the current situation works for 0% of CLISP users. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From ehuels at gmail.com Tue Sep 30 13:49:54 2008 From: ehuels at gmail.com (Erik Huelsmann) Date: Tue Sep 30 13:50:00 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> Message-ID: On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer wrote: > >> The reason it's not there yet is that I'm unaware of a good way to >> detect which libc version is installed on a system. Or would it always >> be libc.so.6? > > I suppose libc5 is outdated enough to forget about it > and a libc7 is still far away. :) > > So the libc6 statement would work for 99% of UNIX users Unix or Linux? What statement would we need on Solaris/ *BSD? > whereas the current situation works for 0% of CLISP users. Well, if it really didn't work, I wouldn't have included it in the distribution. It's definitely working for me: Debian/Etch on x86. Are any of you also using Debian yet experiencing problems? If so, maybe we need to figure out the difference between our installations? Bye, Erik. From xach at xach.com Tue Sep 30 16:31:37 2008 From: xach at xach.com (Zach Beane) Date: Tue Sep 30 16:31:45 2008 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> Message-ID: <20080930203137.GU7270@xach.com> On Tue, Sep 30, 2008 at 07:49:54PM +0200, Erik Huelsmann wrote: > On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer > wrote: > > > >> The reason it's not there yet is that I'm unaware of a good way to > >> detect which libc version is installed on a system. Or would it always > >> be libc.so.6? > > > > I suppose libc5 is outdated enough to forget about it > > and a libc7 is still far away. :) > > > > So the libc6 statement would work for 99% of UNIX users > > Unix or Linux? What statement would we need on Solaris/ *BSD? > > > whereas the current situation works for 0% of CLISP users. > > Well, if it really didn't work, I wouldn't have included it in the > distribution. It's definitely working for me: Debian/Etch on x86. Are > any of you also using Debian yet experiencing problems? > > If so, maybe we need to figure out the difference between our installations? The current release doesn't compile on CLISP for me on Mac OS X 10.5 or Ubuntu Linux 8.04. Zach From binghe.lisp at gmail.com Sun Sep 7 15:09:40 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun, 7 Sep 2008 23:09:40 +0800 Subject: [usocket-devel] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT Message-ID: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> Hi, usocket Just found a bug on 0.4.x branch, on LispWorks (non-win32 version). The WAIT-FOR-INPUT-INTERNAL function has a TRUNCATE operation on TIMEOUT: (defun wait-for-input-internal (wait-list &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? (dolist (x (wait-list-waiters wait-list)) (mp:notice-fd (os-socket-handle x))) (mp:process-wait-with-timeout "Waiting for a socket to become active" (truncate timeout) ;; IT'S HERE!!!!!!!!!!!!!!!!!!!!!!!!! #'(lambda (socks) (let (rv) (dolist (x socks rv) (when (usocket-listen x) (setf (state x) :READ rv t))))) (wait-list-waiters wait-list)) (dolist (x (wait-list-waiters wait-list)) (mp:unnotice-fd (os-socket-handle x))) wait-list))) So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT keyword supply, (TRUNCATE NIL) will be called, and error happens. How to fix this issue to make sure I can just wait "infinitely" on a usocket? Regards, Chun Tian (binghe) From hans at huebner.org Sun Sep 7 15:33:49 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 7 Sep 2008 17:33:49 +0200 Subject: [usocket-devel] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT In-Reply-To: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> References: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> Message-ID: On Sun, Sep 7, 2008 at 17:09, Chun Tian (binghe) wrote: > So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT keyword > supply, (TRUNCATE NIL) will be called, and error happens. How to fix this > issue to make sure I can just wait "infinitely" on a usocket? Not having tried it, but (and timeout (truncate timeout)) should do, no? -Hans From binghe.lisp at gmail.com Sun Sep 7 15:46:55 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun, 7 Sep 2008 23:46:55 +0800 Subject: [usocket-devel] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT In-Reply-To: References: <4FF2F3CB-5C47-4E61-9FA7-D117E402DEB6@gmail.com> Message-ID: <91FB7110-B184-459A-8069-AAA86B394908@gmail.com> ? 2008-9-7???11:33? Hans H?bner ??? > On Sun, Sep 7, 2008 at 17:09, Chun Tian (binghe) > wrote: > >> So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT >> keyword >> supply, (TRUNCATE NIL) will be called, and error happens. How to >> fix this >> issue to make sure I can just wait "infinitely" on a usocket? > > Not having tried it, but (and timeout (truncate timeout)) should do, > no? I don't think so. MP:PROCESS-WAIT-WITH-TIMEOUT must be called with a TIMEOUT parameter as integer (in seconds). If TIMEOUT is NIL, WAIT-FOR-INPUT-INTERNAL maybe should turn to call MP:PROCESS-WAIT instead of MP:PROCESS-WAIT- WITH-TIMEOUT: http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-445.htm I made a patch based on above idea, as in attach, it works under simple test. Regards, Chun Tian (binghe) -------------- next part -------------- A non-text attachment was scrubbed... Name: usocket-wfl-lispworks.diff Type: application/octet-stream Size: 1535 bytes Desc: not available Url : http://common-lisp.net/pipermail/usocket-devel/attachments/20080907/fffa6558/attachment.obj -------------- next part -------------- From ehuels at gmail.com Thu Sep 18 15:45:32 2008 From: ehuels at gmail.com (Erik Huelsmann) Date: Thu, 18 Sep 2008 17:45:32 +0200 Subject: [usocket-devel] Re: usocket-devel post from larsnostdal@gmail.com requires approval In-Reply-To: References: Message-ID: Hi Lars! Thanks for the report. Sorry for the delay; I finally committed your fix. I've applied a similar fix to SOCKET-LISTEN. Bye, Erik. On Tue, Aug 26, 2008 at 2:10 PM, wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: usocket-devel at common-lisp.net > From: larsnostdal at gmail.com > Subject: [Fwd: Don't want FD leaks (patch)] > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > http://common-lisp.net/cgi-bin/mailman/admindb/usocket-devel > > to approve or deny the request. > > > ---------- Forwarded message ---------- > From: Lars Rune N?stdal > To: usocket-devel at common-lisp.net > Date: Tue, 26 Aug 2008 14:11:33 +0200 > Subject: [Fwd: Don't want FD leaks (patch)] > > > > ---------- Forwarded message ---------- > From: Lars Rune N?stdal > To: > Date: Tue, 26 Aug 2008 14:04:09 +0200 > Subject: Don't want FD leaks (patch) > Hi, > Noticed that FDs leak in some cases. Quick test and a patch: > > (defun test () > (loop > (handler-case > (let ((socket (usocket:socket-connect "aoeuaoeu.com" 80))) > (princ socket) (terpri)) > (t (c) > (format t "do i leak? ~A~%" c))))) > > > I use lsof to test for leaks while this is running: > lnostdal at blackbox:~/programming/lisp/usocket$ lsof -a -p 25803 | nl > > Here is the patch; not tested much but seems to work for me: > > > lnostdal at blackbox:~/programming/lisp/usocket$ svn diff > Index: backend/sbcl.lisp > =================================================================== > --- backend/sbcl.lisp (revision 423) > +++ backend/sbcl.lisp (working copy) > @@ -213,27 +213,32 @@ > (not (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay))) > (unsupported 'nodelay 'socket-connect)) > > - (let* ((socket (make-instance 'sb-bsd-sockets:inet-socket > - :type :stream :protocol :tcp)) > - (stream (sb-bsd-sockets:socket-make-stream socket > - :input t > - :output t > - :buffering :full > - :element-type element-type)) > - ;;###FIXME: The above line probably needs an :external-format > - (usocket (make-stream-socket :stream stream :socket socket)) > - (ip (host-to-vector-quad host))) > - (when (and nodelay-specified > - (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay)) > - (setf (sb-bsd-sockets:sockopt-tcp-nodelay socket) nodelay)) > - (when (or local-host local-port) > - (sb-bsd-sockets:socket-bind socket > - (host-to-vector-quad > - (or local-host *wildcard-host*)) > - (or local-port *auto-port*))) > - (with-mapped-conditions (usocket) > - (sb-bsd-sockets:socket-connect socket ip port)) > - usocket)) > + (let ((socket (make-instance 'sb-bsd-sockets:inet-socket > + :type :stream :protocol :tcp))) > + (handler-case > + (let* ((stream (sb-bsd-sockets:socket-make-stream socket > + :input t > + :output t > + :buffering :full > + :element-type element-type)) > + ;;###FIXME: The above line probably needs an :external-format > + (usocket (make-stream-socket :stream stream :socket socket)) > + (ip (host-to-vector-quad host))) > + (when (and nodelay-specified > + (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay)) > + (setf (sb-bsd-sockets:sockopt-tcp-nodelay socket) nodelay)) > + (when (or local-host local-port) > + (sb-bsd-sockets:socket-bind socket > + (host-to-vector-quad > + (or local-host *wildcard-host*)) > + (or local-port *auto-port*))) > + (with-mapped-conditions (usocket) > + (sb-bsd-sockets:socket-connect socket ip port)) > + usocket) > + (t (c) > + ;; Make sure we don't leak filedescriptors. > + (sb-bsd-sockets:socket-close socket) > + (error c))))) > > (defun socket-listen (host port > &key reuseaddress > > > > -- > Lars Rune N?stdal || AJAX/Comet GUI type stuff for Common Lisp > http://nostdal.org/ || http://groups.google.com/group/symbolicweb > > > ---------- Forwarded message ---------- > From: usocket-devel-request at common-lisp.net > To: > Date: > Subject: confirm c133299de2b1ebf623d1c8e5ce04db0e85ab23b7 > If you reply to this message, keeping the Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply. > From xach at xach.com Sat Sep 27 21:12:53 2008 From: xach at xach.com (Zach Beane) Date: Sat, 27 Sep 2008 17:12:53 -0400 Subject: [usocket-devel] Compile failure on CLISP 2.46 Message-ID: <20080927211253.GI7270@xach.com> When compiling usocket 0.3.7 on CLISP 2.46, I get this error: ;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist Any ideas? Zach From sky at viridian-project.de Sat Sep 27 22:30:53 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 28 Sep 2008 00:30:53 +0200 (CEST) Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <20080927211253.GI7270@xach.com> References: <20080927211253.GI7270@xach.com> Message-ID: <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> > When compiling usocket 0.3.7 on CLISP 2.46, I get this error: > > ;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... > ** - Continuable Error > FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not > exist > > Any ideas? Does it work if you put this: (ffi:default-foreign-language :stdc) (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is into your ~/.clisprc ? Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From sky at viridian-project.de Sat Sep 27 22:37:37 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 28 Sep 2008 00:37:37 +0200 (CEST) Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> Message-ID: <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> > Does it work if you put this: > > (ffi:default-foreign-language :stdc) > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is > > into your ~/.clisprc ? If this doesn't help, try adding #+unix (:library "libc.so.6") ;; or darwin if you need it in backend/clisp.lisp, right below: (FFI:DEF-CALL-OUT get-host-name-internal (:name "gethostname") (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) :OUT :ALLOCA) (len ffi:int)) #+win32 (:library "WS2_32") -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From xach at xach.com Sat Sep 27 23:54:51 2008 From: xach at xach.com (Zach Beane) Date: Sat, 27 Sep 2008 19:54:51 -0400 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> Message-ID: <20080927235451.GJ7270@xach.com> On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote: > > > Does it work if you put this: > > > > (ffi:default-foreign-language :stdc) > > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is > > > > into your ~/.clisprc ? > > If this doesn't help, try adding > > #+unix (:library "libc.so.6") ;; or darwin if you need it > > in backend/clisp.lisp, right below: > > (FFI:DEF-CALL-OUT get-host-name-internal > (:name "gethostname") > (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) > :OUT :ALLOCA) > (len ffi:int)) > #+win32 (:library "WS2_32") I used #+macos (:library "libc.dylib") and it did the trick, thanks. I think a similar trick may be needed on non-Mac Unixes. Zach From binghe.lisp at gmail.com Sun Sep 28 06:51:29 2008 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Sun, 28 Sep 2008 14:51:29 +0800 Subject: [usocket-devel] What if a usocket instance be garbage collected? Message-ID: <8442E1E3-5C39-47A7-81A3-E3FBBF177805@gmail.com> Hi, usocket devel If a usocket instance has been garbage collected (or just cannot refer to it, i. e. lost it by set the variable to new value), does anyone (either usocket or CL platform) will consider closing the correspond socket fd automatically? I know at least one CL platform, LispWorks, has some related API (HCL:ADD-SPECIAL-FREE-ACTION) [1], and I want to use it in my UDP applications. Just don't know if this will be a common feature to be considered by usocket itself. Any opinions? --binghe [1] http://www.lispworks.com/documentation/lw51/LWUG/html/lwuser-149.htm#pgfId-890008 From ehuels at gmail.com Mon Sep 29 19:52:21 2008 From: ehuels at gmail.com (Erik Huelsmann) Date: Mon, 29 Sep 2008 21:52:21 +0200 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <20080927235451.GJ7270@xach.com> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> Message-ID: On Sun, Sep 28, 2008 at 1:54 AM, Zach Beane wrote: > On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote: >> >> > Does it work if you put this: >> > >> > (ffi:default-foreign-language :stdc) >> > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is >> > >> > into your ~/.clisprc ? >> >> If this doesn't help, try adding >> >> #+unix (:library "libc.so.6") ;; or darwin if you need it >> >> in backend/clisp.lisp, right below: >> >> (FFI:DEF-CALL-OUT get-host-name-internal >> (:name "gethostname") >> (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) >> :OUT :ALLOCA) >> (len ffi:int)) >> #+win32 (:library "WS2_32") > > I used #+macos (:library "libc.dylib") and it did the trick, thanks. I > think a similar trick may be needed on non-Mac Unixes. The reason it's not there yet is that I'm unaware of a good way to detect which libc version is installed on a system. Or would it always be libc.so.6? Bye, Erik. From sky at viridian-project.de Tue Sep 30 08:22:46 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 30 Sep 2008 10:22:46 +0200 (CEST) Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> Message-ID: <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> > The reason it's not there yet is that I'm unaware of a good way to > detect which libc version is installed on a system. Or would it always > be libc.so.6? I suppose libc5 is outdated enough to forget about it and a libc7 is still far away. :) So the libc6 statement would work for 99% of UNIX users whereas the current situation works for 0% of CLISP users. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From ehuels at gmail.com Tue Sep 30 17:49:54 2008 From: ehuels at gmail.com (Erik Huelsmann) Date: Tue, 30 Sep 2008 19:49:54 +0200 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> Message-ID: On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer wrote: > >> The reason it's not there yet is that I'm unaware of a good way to >> detect which libc version is installed on a system. Or would it always >> be libc.so.6? > > I suppose libc5 is outdated enough to forget about it > and a libc7 is still far away. :) > > So the libc6 statement would work for 99% of UNIX users Unix or Linux? What statement would we need on Solaris/ *BSD? > whereas the current situation works for 0% of CLISP users. Well, if it really didn't work, I wouldn't have included it in the distribution. It's definitely working for me: Debian/Etch on x86. Are any of you also using Debian yet experiencing problems? If so, maybe we need to figure out the difference between our installations? Bye, Erik. From xach at xach.com Tue Sep 30 20:31:37 2008 From: xach at xach.com (Zach Beane) Date: Tue, 30 Sep 2008 16:31:37 -0400 Subject: [usocket-devel] Compile failure on CLISP 2.46 In-Reply-To: References: <20080927211253.GI7270@xach.com> <61100.88.73.226.176.1222554653.squirrel@mail.stardawn.org> <61574.88.73.226.176.1222555057.squirrel@mail.stardawn.org> <20080927235451.GJ7270@xach.com> <63182.88.73.243.108.1222762966.squirrel@mail.stardawn.org> Message-ID: <20080930203137.GU7270@xach.com> On Tue, Sep 30, 2008 at 07:49:54PM +0200, Erik Huelsmann wrote: > On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer > wrote: > > > >> The reason it's not there yet is that I'm unaware of a good way to > >> detect which libc version is installed on a system. Or would it always > >> be libc.so.6? > > > > I suppose libc5 is outdated enough to forget about it > > and a libc7 is still far away. :) > > > > So the libc6 statement would work for 99% of UNIX users > > Unix or Linux? What statement would we need on Solaris/ *BSD? > > > whereas the current situation works for 0% of CLISP users. > > Well, if it really didn't work, I wouldn't have included it in the > distribution. It's definitely working for me: Debian/Etch on x86. Are > any of you also using Debian yet experiencing problems? > > If so, maybe we need to figure out the difference between our installations? The current release doesn't compile on CLISP for me on Mac OS X 10.5 or Ubuntu Linux 8.04. Zach