[usocket-devel] Problem with :ready-only

[Chun Tian (binghe)]

Hi, Daniel

Thanks, this time I fully understand what you're talking about.

> Thanks for the reply, but I have some issues:
> 
> (1) ready-only should be documented in the doc string.

DONE. You'll see it in our next release.

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

Agree!

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

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.


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

Agree, too.

> 
> (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, and provide more information for me to confirm:

* The CL implementation you're using, 
* Operating System (OS) you're using.
* Some kind of test code, if possible.

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