Preamble: I admit, I find event driven programming ugly. It destroys the natural flow of the program by breaking up loops and turning them into three separate pieces of code. Simple, sequential tasks also get broken up and scattered around. This is why I find HTTP and POE ugly. But, as you have seen, event driven programming can give good results, that's why one resorts to it. I'm always looking for good alternatives to event driven programming :

Fresh on the CPAN is Net::Socket::NonBlock, but it is in a really early version (and I haven't played with it at all). Depending on its API, it might implement enough buffering such that your program flow won't have to take much into account that it is really multiple sessions.

Another option to consider is the Coro module - coroutines (and, much more interesting, cooperative multitasking) in Perl. Its performance isn't as high as it could be, and it isn't as portable as it could be (I don't know if it works on Win32 now :-(), but it allows you easy threaded programming without the headaches of real multithreading. The only drawback is, of course, that disk IO is still synchronous, so if disk IO becomes the bottleneck, you're maybe better off to spawn a separate IO worker process and connect to that via another socket. I have played with the Coro module, but not under Win32.

The third option would be to use a database for synchronisation. This has the drawback of being really slow, but it has the advantage of being resumable if your program crashes. iI you're looking for a "lightweight" database, take a look at DBD::SQLite - but if you're doing much writing to that database, you will spend more time waiting for the file locks than actually doing anything else.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]