[usocket-devel] usocket on LispWorks (non-win32 and no multiprocessing)
Hi, usocket-devel (testing 0.4 branch) In LispWorks Professional and Enterprise Edition, user can save a image without thread support. When such a lispworks image started, all function in MP package is there but no thread running: binghe@binghe-debian:~$ lispworks-cli LispWorks(R): The Common Lisp Programming Environment Copyright (C) 1987-2008 LispWorks Ltd. All rights reserved. Version 5.1.1 Saved by binghe as lispworks-5-1-1-64-bit-cli, at 12 Jun 2008 14:50 User binghe on binghe-debian.local CL-USER 1 > (mp:list-all-processes) NIL CL-USER 3 > mp:*current-process* NIL When there's no thread support in LispWorks, USOCKET:WAIT-FOR-INPUT cannot be used (on non-win32 platform) because it calls MP:PROCESS- WAIT on current thread, that will cause a UNKNOWN-ERROR: USOCKET 9 > (wait-for-input x) Error: The condition #<UNKNOWN-ERROR 405008A5B0> occurred 1 (abort) Return to level 0. 2 Restart top-level loop. Type :b for backtrace, :c <option number> to proceed, or :? for other options USOCKET 10 : 1 > :b Call to ERROR Call to RAISE-USOCK-ERR Call to SIGNAL Call to ERROR Call to MP::WITHOUT-PREEMPTION-ERROR Call to MP:PROCESS-WAIT Call to WAIT-FOR-INPUT-INTERNAL Call to WAIT-FOR-INPUT Call to WAIT-FOR-INPUT Call to EVAL I think may be there're some way not use MP-related function to achieve the same effect, i.e. direct call select() or turn to use LispWorks' SYS:WAIT-FOR-INPUT-STREAMS [1] instead (which works on all platform include win32 but just for stream usocket). Regards, Chun Tian (binghe) [1] http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-765.htm#pgfId-12...
On Tue, Oct 21, 2008 at 1:24 PM, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:
Hi, usocket-devel
(testing 0.4 branch)
In LispWorks Professional and Enterprise Edition, user can save a image without thread support. When such a lispworks image started, all function in MP package is there but no thread running:
binghe@binghe-debian:~$ lispworks-cli LispWorks(R): The Common Lisp Programming Environment Copyright (C) 1987-2008 LispWorks Ltd. All rights reserved. Version 5.1.1 Saved by binghe as lispworks-5-1-1-64-bit-cli, at 12 Jun 2008 14:50 User binghe on binghe-debian.local
CL-USER 1 > (mp:list-all-processes) NIL
CL-USER 3 > mp:*current-process* NIL
When there's no thread support in LispWorks, USOCKET:WAIT-FOR-INPUT cannot be used (on non-win32 platform) because it calls MP:PROCESS- WAIT on current thread, that will cause a UNKNOWN-ERROR:
Nice catch!
USOCKET 9 > (wait-for-input x)
Error: The condition #<UNKNOWN-ERROR 405008A5B0> occurred 1 (abort) Return to level 0. 2 Restart top-level loop.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
USOCKET 10 : 1 > :b Call to ERROR Call to RAISE-USOCK-ERR Call to SIGNAL Call to ERROR Call to MP::WITHOUT-PREEMPTION-ERROR Call to MP:PROCESS-WAIT Call to WAIT-FOR-INPUT-INTERNAL Call to WAIT-FOR-INPUT Call to WAIT-FOR-INPUT Call to EVAL
I think may be there're some way not use MP-related function to achieve the same effect, i.e. direct call select() or turn to use LispWorks' SYS:WAIT-FOR-INPUT-STREAMS [1] instead (which works on all platform include win32 but just for stream usocket).
Well, that would severely limit the usability of WAIT-FOR-INPUT, because it wouldn't be usable with listening sockets or udp sockets. Could we just error out when someone tries to use WAIT-FOR-INPUT without MP support? I mean... Are there any problems with requiring the apps be built with mp support? (licensing from LW, for example) Bye, Erik.
On Tue, Oct 21, 2008 at 1:24 PM, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:
Hi, usocket-devel
(testing 0.4 branch)
In LispWorks Professional and Enterprise Edition, user can save a image without thread support. When such a lispworks image started, all function in MP package is there but no thread running:
binghe@binghe-debian:~$ lispworks-cli LispWorks(R): The Common Lisp Programming Environment Copyright (C) 1987-2008 LispWorks Ltd. All rights reserved. Version 5.1.1 Saved by binghe as lispworks-5-1-1-64-bit-cli, at 12 Jun 2008 14:50 User binghe on binghe-debian.local
CL-USER 1 > (mp:list-all-processes) NIL
CL-USER 3 > mp:*current-process* NIL
When there's no thread support in LispWorks, USOCKET:WAIT-FOR-INPUT cannot be used (on non-win32 platform) because it calls MP:PROCESS- WAIT on current thread, that will cause a UNKNOWN-ERROR:
Nice catch!
USOCKET 9 > (wait-for-input x)
Error: The condition #<UNKNOWN-ERROR 405008A5B0> occurred 1 (abort) Return to level 0. 2 Restart top-level loop.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
USOCKET 10 : 1 > :b Call to ERROR Call to RAISE-USOCK-ERR Call to SIGNAL Call to ERROR Call to MP::WITHOUT-PREEMPTION-ERROR Call to MP:PROCESS-WAIT Call to WAIT-FOR-INPUT-INTERNAL Call to WAIT-FOR-INPUT Call to WAIT-FOR-INPUT Call to EVAL
I think may be there're some way not use MP-related function to achieve the same effect, i.e. direct call select() or turn to use LispWorks' SYS:WAIT-FOR-INPUT-STREAMS [1] instead (which works on all platform include win32 but just for stream usocket).
Well, that would severely limit the usability of WAIT-FOR-INPUT, because it wouldn't be usable with listening sockets or udp sockets.
Could we just error out when someone tries to use WAIT-FOR-INPUT without MP support? I mean... Are there any problems with requiring the apps be built with mp support? (licensing from LW, for example)
Yes, I think just limit the use of WAIT-FOR-INPUT on "LispWorks with MP enabled" is OK, but following things should be done: * When usocket is loading on LispWorks without MP enabled, a warn should be output. I found a piece of code in GBBopen's portable- threads.lisp, may help: ;;; --------------------------------------------------------------------------- ;;; Warn if multiprocessing is not running on Lispworks #+lispworks (defun check-for-multiprocessing-started (&optional errorp) (unless mp:*current-process* (funcall (if errorp 'error 'warn) "You must start multiprocessing on Lispworks by calling~ ~%~3t(~s)~ ~%for ~s, locks, and other thread operations to function ~ properly." 'initialize-multiprocessing 'with-timeout))) #+lispworks (check-for-multiprocessing-started) * When WAIT-FOR-INPUT is called on LispWorks without MP enabled, a better error should be signaled to tell user the MP should be enabled. If you agree, I'll try to commit some code according to above two points. --binghe
participants (2)
-
Chun Tian (binghe) -
Erik Huelsmann