I've run into a strange issue while testing my application on Windows. This does not occur on Linux. It is a racket/gui app that uses a custom subclass of canvas% that I wrote.
When dragging the scroll bar on Windows, if there is a printf call in the callback for on-scroll or on-paint, the thread handling the callback appears to stall while I drag the scrollbar around. No canvas updates or prints occur until I release the left mouse button. After releasing the mouse button, a large number of queued events are then handled and I see the drawing and printfs.
If I map the current-output-port to (open-output-nowhere), it no longer happens. So it appears that the writes to stdout in the callback are blocking.
Is this expected behavior? A bug? Is it possible that something in my app is causing a deadlock on the output port while dragging the scroll bar?
This is a limitation of racket/gui for Windows (and Mac OS).
The platform's GUI toolkit reports the scroll to racket/gui through a callback, but racket/gui can't safely switch to other Racket threads during the callback. Also, the platform GUI toolkit doesn't return back to the Racket-driven event loop until scrolling is done.
During the callback, racket/gui makes an effort to perform its work, but if that work takes too long or if it involves a thread synchronization, then racket/gui has to give up until scrolling is done. (It grabs a low-level continuation, if necessary, to finish any work that stalled.)
Printing to (open-output-nowhere) doesn't need to block, but other output ports often do.
Thanks for the explanation. Output is something I can easily avoid doing, so it isn't a serious problem. I just feel a lot better knowing why this was happening!