Racket provides support for concurrency via lightweight threads, which the web server leverages to handle requests, spawning one such thread per incoming request. At the runtime level, these threads run concurrently but not in parallel (i.e., only one thread is active at any one time). Parallelism is available in Racket via Places: distinct instances of the Racket runtime running in separate OS threads that communicate via message passing.
The web server doesn’t do anything with places, so, by default, all Racket web servers run in a single OS thread. That isn’t a big deal since you can run one web server process per core and place a reverse proxy like Nginx in front to load balance between the processes. But what if you don’t want to do that? Is there a way to use the web server in conjunction with places despite the web server lacking explicit support for them?
I recently ran across Matthew D. Miller’s “Survey of the State of GUI
Programming in Lisp” series on implementing a small GUI
application across various LISP implementations. The first
article in that series uses
racket/gui, so I figured I’d
take a stab at porting that implementation to gui-easy. You can
find my port here.
As of iOS 14.4, non-debugged builds (i.e. ones run outside of XCode) fail with a dynamic code signing error and there is no way to work around this at the moment.
A couple of weeks ago, I started working on getting Racket CS to compile and run on iOS and, with a lot of guidance from Matthew Flatt, I managed to get it working (with some caveats). Those changes have now been merged, so I figured I’d write another one of these guides while the information is still fresh in my head.