The primary reason that it has threading support is to support forking emulation, because Windows does not have a OS-level fork call. (See perlfork.) You should be able to access threads this way, but beware that Win32::GUI might have some problems if you spawn threads while it's objects are in scope because it's (XS-based) destructors could be called prematurely, or twice. update: (These problems may occur if you merely have such objects in exsitence at time of forking, even.)

Well, since you don't recomend threads, can you suggest a method to allow the program to send/rescieve the data necessary without locking up? Is it possible to do it with fork? If you have any potential solution, please explain it in detail... I'd like to learn, instead of just have the answer handed to me.

Thanks


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- w+ O---- M-- V--
PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
------END GEEK CODE BLOCK------
Translate

"Weird things happen, get used to it."

Flame ~ Lead Programmer: GMS

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.)