<br><div class="gmail_quote">On Sat, Oct 24, 2009 at 8:06 AM, Nadeem Abdul Hamid <span dir="ltr"><<a href="mailto:nadeem@acm.org" target="_blank">nadeem@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Fri, Oct 23, 2009 at 9:35 PM, Nadeem Abdul Hamid <<a href="mailto:nadeem@acm.org" target="_blank">nadeem@acm.org</a>> wrote:<br>
><br>
> The delay causes the code to "hang" for about 5 to 10 seconds before<br>
> it the read comes through. An interval of 5 causes a much longer<br>
> "hang". And as YC suggested, the CPU usage is max-ed out during that<br>
> period...<br>
><br>
<br>
</div>Sorry, this was dumb. It delays exactly as expected. I've been working<br>
on this too long...<br>
</blockquote></div><br>Nadeem - <br><br>to reduce the CPU usage you can use sync or the blocking variety of the read-* functions, so that you are not melting your computer waiting for the bytes to come through. Looking at your function's logic it doesn't appear you need the non-blocking methods, and the logic appears very similar to read-bytes, but it returns a list of bytes instead of a byte-string. So something like the below should work:<br>
<br>(define (read-bytes/list num in) <br> (bytes->list (read-bytes num in))) <br><br>read-bytes will hang unless it has captured enough bytes or encounter an EOF. If you need the function to return before encountering EOF but doesn't hang forever - you can use other mechanisms, such as installing a max timeout:<br>
<br>(define (read-bytes/list/timeout num in timeout)<br> (define (helper alarm acc count)<br> (let ((evt (sync alarm in))) <br> (if (eq? alarm evt)<br> (reverse acc)<br> (let ((b (read-byte in))) <br>
(cond ((eof-object? b) <br> (if (null? acc) <br> b<br> (reverse acc)))<br> ((= (add1 count) num)<br> (reverse (cons b acc)))<br>
(else<br> (helper alarm (cons b acc) (add1 count))))))))<br> (helper (alarm-evt (+ (current-inexact-milliseconds) (* 1000 timeout))) '() 0))<br><br>In any event, it's likely that the issue lies at the port level if your simulation that provides a deterministic flow of bytes works correctly even when the cpu is maxed out. You might have better luck to investigate the port to make sure the data is flowing through. <br>
<br>HTH,<br>yc<br><br>