I thought this task would be relatively easy. Basically, you'd fork off a "server" at the beginning of your script which would have a channel to your script, probably created with pipe. You'd send URLs to get over a pipe, and the other end would read them, fetch the URL, and return the URL over another pipe. (This scheme would basically be what is done under "Bidirectional Communication with Yourself" in perlipc.)

Unfortunately, Win32::GUI makes watching for the response difficult. Under Tk, one can watch for "fileevents" and thus get notified when data is available on a filehandle (from Tk's main loop.) Win32::GUI does not have a generic filehandle watching mechanism. One could probably emulate it using Win32::GUI::Timer and non-blocking I/O:

Basically, you'd periodically poll the pipe going into your script to see if it has data for you. So regularly, you'd try to sysread from your pipe which has been set non-blocking (so your GUI won't freeze). (update: You'd probably schedule these read attempts with Win32::GUI::Timer, of course.) I reccommend sysread, because you're probably going to need to do your own I/O buffering this case. You probably want a relatively short time interval, something to balance use of CPU with apparent speed. To enable non-blocking I/O, you'd use IO::Handle's blocking method with an argument of 0. To check for data from the socket, you'd read it (with sysread) and see if you got an error (undef return). If you got an error and $! was EAGAIN (see the Errno module), then there is no data on the pipe. If $! wasn't EAGAIN, but there was an error, then you'd probably want to die, because something weird would've happened. If you don't get an error, you can add that to your cache of the results (note that you probably won't get all such data at once). (You probably want to have some way of marking when the end of data is, possibly just prefixing data you send with the length of the data.)

Personally, I'd prefer a solution where Win32::GUI was modified to support watching filehandles.

update: I forewarn that this advice is untested. (Also updated phrasing slightly.)