hexchat
hexchat copied to clipboard
hexchat
IO Related Freezing during XDCC receive
It seems to me that the problem below is thread/process management related and probably platform dependent.
When the download folder is changed to a (slow) external hard drive, hexchat immediately freezes upon receiving a large file. The file size (as shown by ls) grows as hexchat is frozen, so it's not as if the whole program has crashed. If I cut the internet connection the UI is immediately responsive again. My internet speed is very fast, almost certainly faster than the external hard drive's write speed, which may be related.
Similarly, I changed the download folder to be on my SSD and set it to move to the hard drive after the download completed. The UI was responsive throughout receiving the file, but once it completed and it started moving to the hard drive it froze and exhibited the same behavior.
After the move finished, hexchat immediately popped back into focus and I had timed out from the network during the move, so it's not just the UI freezing during IO.
I'm using the package of 2.10.2 available from the website. Hexchat was installed immediately before noticing this bug and no settings were changed other than the ones mentioned. OS X 10.11.2
Really? I've never experienced this with hexchat on Windows or Linux but I guess I had lower network/write speed ratios then. So you're saying that hexchat is blocking in chunks, and the network and write speed mismatch means it must immediately go onto the next chunk without time to execute anything other than IO?
I'm honestly more surprised that it blocks the entire time it moves the file locally.
When the GUI is blocked, it cannot service requests, such as requests to repaint the UI, thus the OS renders it as frozen.
Writing a file uses blocking I/O. Once a write has begun the GUI is blocked on it until the write has completed. Each chunk of received DCC data results in a write to the target file.
If chunks are received faster than they can be processed, HC will always have more data to process and thus will never exit the processing loop to be able to service UI requests.
Moving a file uses blocking I/O. Once a move has begun the GUI is blocked on it until the move has completed. A cross-disk move requires reading and writing the entire file instead of simply updating some directory structures, thus the time it takes is a function of the source disk's read speed and the target disk's write speed.
Making the move operation async should be easy since it is pretty self contained, making all writes async would be a bit more work.
Making writes async is unnecessary. All we need to fix is this:
If chunks are received faster than they can be processed, HC will always have more data to process and thus will never exit the processing loop to be able to service UI requests.
That is, we could just remove the while(1) loop around the calls to recv() so that only one received buffer is processed at a time and UI stays responsive.
Windows 10 and Hexchat 2.14.2 (x64). I changed my XDCC download folder to be network drive on my NAS and I noticed UI freeze. It freezes the moment transfer starts and stops when transfer is finished.
Between files in a batch, it also disconnects from the IRC network. It seems to have be related to the file size, files above 80Mb almost always cause a disconnect.
Same issue here although I see that the network speed is limited to 10MB/sec when writing to the network drive and therefore also receiving. When performing the same transfer to a local drive I receive at full speed which is 70MB/sec for this transfer.
..same here, HExChat freezes, when download dir is on NAS, but its still DCC transfer!
2.16.0(x64) on Windows10 and Windows 11 and the issue still exist. XDCC receive cames in, you hit download and the whole Hexchat freezes until the download is finished (or maybe sometimes even forever). This happens not every time but quite often.
I moved away from hexchat for file transfers in the end. Network activity speaks for itself: green box is a receive in hexchat, blue box is the same transfer/sender after cancelling and performing through mirc
.
Nothing. I try it out from time to time. I don't think they will ever solve the problem.