DCC does blocking IO everywhere, it is awful.

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.

Any write could still block for too long ofc, so less than ideal.

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!

Facing the same issues on 2.12.3(x64), Windows PC

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

.

I'm also having the freezing issue. Any update on a fix?
2.16.1

Nothing. I try it out from time to time. I don't think they will ever solve the problem.