Notice: All "READ-ONLY" in past mail should be "READY-ONLY".
--binghe 在 2010-6-28，23:48， Chun Tian (binghe) 写道： > 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 >> [email protected] >> http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel > _______________________________________________ usocket-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
