<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Chun Tian (binghe) wrote:<br>
<blockquote cite="mid:54DDA281-527D-464F-B2FF-EC8B3F70060D@gmail.com"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
<blockquote cite="mid:54DDA281-527D-464F-B2FF-EC8B3F70060D@gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">(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.
</pre>
</blockquote>
<pre wrap=""><!---->
If this library is also a open source project. I'd like you point out it,</pre>
</blockquote>
It was Hunchentoot.<br>
<blockquote cite="mid:54DDA281-527D-464F-B2FF-EC8B3F70060D@gmail.com"
type="cite">
<pre wrap=""> and provide more information for me to confirm:
* The CL implementation you're using,
</pre>
</blockquote>
CCL (formerly known as OpenMCL), latest version<br>
<blockquote cite="mid:54DDA281-527D-464F-B2FF-EC8B3F70060D@gmail.com"
type="cite">
<pre wrap="">* Operating System (OS) you're using.
</pre>
</blockquote>
Linux. Ubuntu 8.<br>
<blockquote cite="mid:54DDA281-527D-464F-B2FF-EC8B3F70060D@gmail.com"
type="cite">
<pre wrap="">* Some kind of test code, if possible.
</pre>
</blockquote>
Well, try taking the :ready-only t out of Hunchentoot.<br>
It was added in the trunk, but we were running an<br>
earlier version.<br>
<br>
Thanks very much!<br>
<br>
-- Dna<br>
<br>
<blockquote cite="mid:54DDA281-527D-464F-B2FF-EC8B3F70060D@gmail.com"
type="cite">
<pre wrap="">
--binghe
</pre>
<blockquote type="cite">
<pre wrap="">Thanks!
-- Dan
Chun Tian (binghe) wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>