[racket] Queuing calls to printf

At Mon, 8 Oct 2012 13:58:00 -0600, Kieron Hardy wrote:
> In the GUI, if the call-chain of on-subwindow-event method calls does not
> complete without requiring another thread to run, the mouse-event% will not
> get delivered to the target. And then the target widget of the mouse-event%
> will not operate the way it should, e.g. a slider% will not slide, a
> list-box% will not select, etc..
> 
> Since printf requires another thread to run, adding calls to printf in
> on-subwindow-event, or anything on-subwindow-event calls directly, will
> cause a GUI to break.

Right.

> I find printf's invaluable for sanity checks during debugging and so have
> developed a little wrapper around printf based on a conditional printf
> trick I saw in the MrEd Designer source. Basically the idea is to put the
> printf in a thunk that will be executed at a later time, maybe by another
> thread, and allow the caller (e.g. on-subwindow-event) to complete without
> requiring another thread.
> 
> My questions are these: Is this a safe and practicable approach to use? Am
> I reinventing something that already exists? Does this need to be
> generalized in some way to use a different eventspace or something?

Another option is logging via `log-debug'.