This isn't quite related to other bugs (such as #356311) when searching bugzilla for the words 'hang', 'hung', 'unresponsive'.

After getting multithreaded support for the download tasks queue (bug #420618), we're now experiencing some really bad pauses in other areas that still aren't multithreaded.

The worst area I'd like to document in this bug is when headers are finishing being fetched for a newsgroup, during their (what I'll term as the) save-to-disk phase.  All other pan2 subtasks are completely stopped until the save is finished.  Yes this includes the other multithreaded downloads, too, simultaneously communicating with completely separate unrelated servers.  No pan2 buttons are reactive, no little yellow pop-ups come up, no nuthin' -- until the save-header phase is finished.

I'll attach a .png screenshot of this occurring on Darwin/OSX.

In the attached picture, please note the Task queue window and the bottom-edge bars -- the newsgroup alt.binaries.hdtv.repost has finished fetching "new" headers, and is in the process of saving them to disk at the time of this screenshot.

Now please note the extreme upper-right area of the screenshot.  In the red outlined rectangle area are the Dual G5 CPU indicators.  One CPU is pegged near 100% while the save-headers phase is on.

Near to the CPU indicators, the red arrow points to the Network I/O gauge.  The little bit being received is me listening to a low-bitrate netradio stream (probably Alex Jones or similar brave soul).  The main point here is that there is no network i/o with pan2 -- it is locked up tight until the save-header phase is finished.

Of course I know the Task queue & bottom bars don't show any other downloads going on at this time.  I was trying to keep it simple for this screenshot.  Please believe me saying if there were other downloads going on, they'd all be frozen with no network i/o, until the save-headers phase is finished.

You're probably wondering how I got a screenshot while pan2 is being unresponsive.  I have Apple's X11 (updated to XFree86-4.6.99-cvs) running as a 'rootless' subsystem.  We can still run native OSX tasks such as Grab.app and get the screenshots that way.  ;)

Even with Dual G5 @ 2.7GHz each and advanced circuitry design of this model, it's taking quite a long time to save the headers (20 to 30 seconds or more for the amount shown in the screenshot).  I've recompiled pan2 and most of the prerequisite projects (gtk+, glib, pango, cairo, etc.) to try a range of gcc optimisations, which seems to have shaved a few seconds off the save-header timing -- but it's still way too long while pan2 is totally unresponsive.

I haven't seen any corrupted downloads when they were temporarily frozen.  I believe this is more to do with my setting huge sysctl values for the various send- & recv-spaces:

# sysctl -aA 2>&1 | grep space
net.local.stream.recvspace: 1572864
net.local.stream.sendspace: 1572864
net.local.dgram.recvspace: 1572864
net.inet.tcp.sendspace: 1048576
net.inet.tcp.recvspace: 1048576
net.inet.udp.recvspace: 1048576
net.inet.raw.recvspace: 1048576

I've also turned on keep-alive and selective-acks, and made their timing values short (i.e. do keep-alive pings every ~20secs instead of 2hrs).  (We must turn off delayed-acks due to ISP modem bugs.)  Settings like these ought to help sessions that are temporarily frozen.

But it's mainly the extreme pausing of the user experience with pan2, about which I'm predicting a lot of users will be complaining.

Thanks for reading this, I hope we can make it better before 1.0 comes out.