[usocket-devel] Problem with :ready-only

[Daniel Weinreb]

Chun Tian (binghe) wrote:
> Well, this is the problem: I cannot reproduce the "bug" you met. I added two new simple unit tests into exist USOCKET test suite, to confirm if WAIT-FOR-INPUT could return immediately when :READY-ONLY was supplied, but my test results showed everything is just right.
>
> The WAIT-FOR-INPUT and READY-ONLY related code are shared by all CL implementations, so I also think the issue you met is NOT implementation specific.
>   

>> (5) In particular, our problem was that the
>> call to usocket:wait-for-input was in a library
>> that we use, rather than our own code, so
>> the only way to fix the problem (until we
>> were able to get a new version of the library
>> that has been adjusted) was to modify it
>> locally, which is somewhat undesirable.
>>     
>
> If this library is also a open source project. I'd like you point out it,
It was Hunchentoot.
>  and provide more information for me to confirm:
>
> * The CL implementation you're using, 
>   
CCL (formerly known as OpenMCL), latest version
> * Operating System (OS) you're using.
>   
Linux.  Ubuntu 8.
> * Some kind of test code, if possible.
>   
Well, try taking the :ready-only t out of Hunchentoot.
It was added in the trunk, but we were running an
earlier version.

Thanks very much!

-- Dna

> --binghe
>
>   
>> Thanks!
>>
>> -- Dan
>>
>> Chun Tian (binghe) wrote:
>>     
>>> Hi, Daniel
>>>
>>> I'm very sorry for the late response for your multiple posts on the :READY-ONLY keyword argument of WAIT-FOR-INPUT.
>>>
>>> The short answer for you will be: always use (:READY-ONLY T), and ...
>>>
>>> here is an formal answer from the original designer of WAIT-FOR-INPUT, Erik Huelsmann:
>>>
>>> """
>>> Without the READ-ONLY arg, WAIT-FOR-INPUT will return all sockets in
>>> the original list you passed it. This prevents a new list from being
>>> consed up. Some users of USOCKET were reluctant to use it if it
>>> wouldn't behave that way, expecting it to cost significant performance
>>> to do the associated garbage collection.
>>>
>>> Without the READ-ONLY arg, you need to check the socket STATE slot for
>>> the values documented in usocket.lisp in the usocket class:
>>>
>>> (state
>>>    :initform nil
>>>    :accessor state
>>>    :documentation "Per-socket return value for the `wait-for-input' function.
>>>
>>> The value stored in this slot can be any of
>>> NIL          - not ready
>>> :READ        - ready to read
>>> :READ-WRITE  - ready to read and write
>>> :WRITE       - ready to write
>>>
>>> The last two remain unused in the current version.
>>> ")
>>> """
>>>
>>> In my opinion, this design is reasonable: for performance critical USOCKET applications, programmers should use (:READY-ONLY NIL), the default option, and check the status of each usocket in the waiting list, this prevents unnecessary runtime consing. For simple use, (:READY-ONLY T) is very convenient, you can just found which usocket is readable just from the return value (as a list) of WAIT-FOT-INPUT.
>>>
>>> I hope this mail could solve your confusion.
>>>
>>> Regards,
>>>
>>> Chun Tian (binghe)
>>>
>>>       
>>>> Hi. I just tried out the latest usocket.  It's not working
>>>> properly for me, because wait-for-input returns true
>>>> even when there isn't any input.
>>>>
>>>> If I change the default value of the :ready-only argument to
>>>> wait-for-input to t instead of nil, that fixes the problem.
>>>>
>>>> I don't even understand why this argument
>>>> exists; no caller seems to pass it at all!  What's going
>>>> on here?
>>>>
>>>> Thanks.
>>>>
>>>> -- Dan
>>>>         
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20100629/4460733d/attachment.html>