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 _______________________________________________ usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
