> On Tue, Oct 21, 2008 at 1:24 PM, Chun Tian (binghe)
> <[EMAIL PROTECTED]> 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:
>>
>> [EMAIL PROTECTED]:~$ 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
_______________________________________________
usocket-devel mailing list
usocket-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
