I've pushed a repair that's intended to fix this problem. The bug was in internal handling of file descriptors in the case that poll() is available and epoll() isn't.
In case it's useful, I also added `--enable-racket=auto` support`, which automates the step of building a Racket executable for the current platform toward cross-compilation for a different host. At Sat, 19 Sep 2015 02:59:44 +0000, John Carmack wrote: > On Android, racket seems to be busy waiting instead of blocking. > > I started out with just a read from a socket, and noticed continuous CPU > utilization. > > I added an explicit blocking sync before the read, and it reported that it > was > blocked in the sync most of the time, but it was still using a full CPU core: > > (define evt (peek-bytes-evt 1 0 #f in)) > (define start (current-inexact-milliseconds)) > (sync evt) > (define end (current-inexact-milliseconds)) > (printf "blocked ~a ms\n" (- end start)) > > I then added a (sleep 1.0) statement, which cut the framerate as expected, > but > it was still using a full core. > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
