# Writing to output port from GUI callback function stalls event handling on windows **URL:** \ **Category:** Questions & Answers\ **Created:** [September 28, 2024, 3:10pm UTC](https://racket.discourse.group/t/writing-to-output-port-from-gui-callback-function-stalls-event-handling-on-windows/3185 "2024-09-28T15:10:49Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![jjsimpso](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jjsimpso/32/602_2.png) [@jjsimpso](https://racket.discourse.group/u/jjsimpso)\ **Post date:** [September 28, 2024, 3:10pm UTC](https://racket.discourse.group/t/writing-to-output-port-from-gui-callback-function-stalls-event-handling-on-windows/3185/1 "2024-09-28T15:10:49Z")
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 `printf`s. 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? ---
**Author:** ![benknoble](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/benknoble/32/16_2.png) [@benknoble](https://racket.discourse.group/u/benknoble)\ **Post date:** [September 28, 2024, 4:00pm UTC](https://racket.discourse.group/t/writing-to-output-port-from-gui-callback-function-stalls-event-handling-on-windows/3185/2 "2024-09-28T16:00:16Z")
Is the callback occurring in the GUI thread (eventspace) or elsewhere? Is the output port buffered? ---
**Author:** ![mflatt](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/mflatt/32/6_2.png) [@mflatt](https://racket.discourse.group/u/mflatt)\ **Post date:** [September 28, 2024, 4:17pm UTC](https://racket.discourse.group/t/writing-to-output-port-from-gui-callback-function-stalls-event-handling-on-windows/3185/3 "2024-09-28T16:17:08Z")
> [@jjsimpso](#): > > 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. 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. ---
**Author:** ![jjsimpso](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jjsimpso/32/602_2.png) [@jjsimpso](https://racket.discourse.group/u/jjsimpso)\ **Post date:** [September 28, 2024, 5:49pm UTC](https://racket.discourse.group/t/writing-to-output-port-from-gui-callback-function-stalls-event-handling-on-windows/3185/4 "2024-09-28T17:49:05Z")
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!