Yes, that design will not block your GUI, but it is also a polling design (bad!) and low performance (responsiveness of the buffer being read/emptied, which if the buffer in the pipe is filled, the child process's write() call will sync block). The ideal design uses async Win32 ReadFile with an Event object (which goes into WaitForMultipleObjects, which is Glib on Win32's internal loop I think) or an IOCP queue. Doing an async ReadFile with Perl is extremely complex, since the ReadFile in Win32API::File doesn't have any provisions for truncating the read buffer after the read is done, nor any provisons to prevent you from freeing the scalar's buffer from pure Perl during the async reading (while your Perl process is doing other random things, bytes are randomly being written to the memory block given to C ReadFile, eventually Windows will signal you somehow that the "writing" into the memory block is done and you can look at it/take ownership back of the memory block). I might one day release a CPAN module that fixes the lack of any async I/O capabilty of Perl on Win32 that I never finished but does sorta work.