[usocket-devel] usocket on LispWorks (non-win32 and no multiprocessing)

[Chun Tian (binghe)]

> On Tue, Oct 21, 2008 at 1:24 PM, Chun Tian (binghe)
> <binghe.lisp at 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 at 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