[usocket-devel] Problem with :ready-only

Daniel Weinreb dlw at itasoftware.com
Mon Jun 28 17:51:48 UTC 2010


Thanks for the reply, but I have some issues:

(1) ready-only should be documented in the doc string.

(2) If ready-only is just supposed to be about consing,
it should not change any behavior other than that.

(3) Why it is ever right for wait-for-input to return
when there isn't any input? Is there something
about the intent of :ready-only that would cause
that behavior to be correct? (Not counting the
EINTR case.)

(4) Changing the behavior incompatibly from one
release to the next is undesirable, in general.

(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.

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)
>
> 在 2010-5-4,06:05, Daniel Weinreb 写道:
>
>   
>> 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
>>
>> _______________________________________________
>> usocket-devel mailing list
>> usocket-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20100628/d4c3952f/attachment.html>


More information about the usocket-devel mailing list