Sorry for the short delay. Yes, here's a copy of that:
John Clements
1 Like
Thanks! Adam also reached out via email (I had sent him one a few days ago). Unfortunately, won’t be able to make it to RacketCon.
One other thing that would be a nice project is parallel processing. I might be completely wrong about this, but my understanding is that Racket runs in one OS thread of one process on one core and that (thread ...) uses a preempting model where only one Racket thread is running at a time. Places and futures can be used to enable true parallelism but they require a bunch of work on the part of the programmer. It would be great if Racket threads would automatically shift themselves onto other cores when available.
There are two ways to use your machine's parallelism in Racket: futures and places. It would be difficult to adapt thread to use OS threads because of the way the runtime system is implemented, I believe.
To be a bit more specific, numerous parts of the runtime assume that they do not have to synchronize to ensure that they're only accessed from one OS thread at a time, and thus don't have to be implemented in a thread-safe manner. This includes everything from equal? hash tables to the module registry in the expander to the IO subsystem. Obviously it's possible to add a big lock around everything instead, in the manner of the Python GIL, but that's effectively what futures give you already and isn't really what people want.
Adding fine-grained locking everywhere would be theoretically possible but (a) it would slow down existing Racket programs and (b) adding exactly the right locks everywhere is very hard and would certainly lead to lots of bugs.
1 Like
There are two ways to use your machine's parallelism in Racket: futures and places.
Yup, I mentioned those in my original post. The issue is that futures are basically unusable for normal tasks -- cf this line from 20 Parallelism :
Futures run in parallel as long as they can do so safely, but the notion of “future safe” is inherently tied to the implementation. The distinction between “future safe” and “future unsafe” operations may be far from apparent at the level of a Racket program.
1 Like
Ah, sorry.
And you're certainly right that futures need more work, although they can be used for things here and there. The implementation is designed to be improved as applications make it clear which directions are the important ones. @dominik.pantucek did some work on this; there's this library and maybe more?
I think the biggest improvement that would help people like @dstorrs would be making it more like the Python GIL, in that blocking operations would resume parallel execution after they complete (this is called a "synchronized" operation in the futures docs). It's not clear to me how difficult it would be to make IO operations, in particular, synchronized, but that would be needed to make futures useful in eg web server applications.
One thing to keep in mind is that Racket CS has improved the situation with futures. I found the diff from guide: update discussion on futures for Racket CS · racket/racket@4fcecee · GitHub interesting. In particular:
In the @tech{CS} implementation of Racket, most primitives are
non-blocking, while the @tech{BC} implementation includes many more
blocking or @tech{synchronized} operations.
There definitely are still limitations, but it's a big change from basically-unusable-except-for-specialized-numeric-code. I think as a community we are (certainly I am) still gaining experience with the pragmatics of futures in Racket CS.
I didn't investigate it very deeply, but I recently experimented with futures for basically a parallelized in-directory, and indeed they did not work out. I'd avoided relying on current-directory, but in thinking about it I realized that even directory-exists? implicitly consults the current-security-guard parameter.
2 Likes