Wow, thanks for going to all that trouble! My DoPost and DoGet routines get pretty involved, so I omitted them, preferring not to scare off any help that might otherwise be forthcoming -- and to avoid the inevitable grief for not using the CGI module. :-)

The only possibly relevent factor is that the POST routine is able to change some shared variables -- notably %Admin and %User. The GET routines have non-writing access to these variables as well. By all indications, the sharing works flawlessly. I'm even able to switch ports midstream without a glitch.

To test the code, I created a self-refreshing HTML page and loaded it into two separate windows in my browser (Opera), just to keep the server busy. I then manually caused some POSTs to be sent, using a page with <form>s. The crashes usually occurred a couple GETs after a POST, but always in near proximity to about the fifth or sixth POST. Oddly enough, even after crashing, when Windows reports that it has to terminate perl.exe, the server keeps servicing requests! This keeps up until the next POST, whereupon the house of cards finally collapses.

Opera will continue to reuse an open connection -- even sharing it among different windows -- until it's required to issue a POST. Then it will close one of its connections and open a new one to send the POST, and continue to share that connection with other windows. So my feeling is that the POST itself is a red herring and that it has more to do with connections closing and/or threads exiting.

But the mystery remains as to why the connection stays active (->connected) once Opera abandons it.