Tomasu wrote:

The file descriptor is -1, so a simple check for this will probably fix it.

Though I don't think thats a proper fix, whats the Socket doing in the manager at all if its totally invalid?

KT probably closed it, but the actual socket has not yet been removed from the list.

I just hope that going to poll doesn't harm performance at all. I'd assume it will, since you have to sit and spin in a loop checking poll all the time.

poll has a timeout like select, but things certainly need to be tweaked.

I have been tweaking KT's performance on a LAN and managed to bump up the upload speed over a LAN to 6 MB/s. The poll changes will be included with this commit.

The actual timeout you pass to poll or select has significant impact on upload speeds. With a 1 ms timeout, I manage to get up to 6 MB/s. However this 1 ms timeout increases CPU usage when you are downloading.

Though, seeing that I have put the priority of the uploading thread to IdlePriority (i.e. every other process has higher scheduling priority, and the networking thread is only run when no other processes want the CPU), higher CPU usage shouldn't be that much of a problem.

also, using my dirty hack, things are "ok" it seems mallocing a larger buffer for fd_set is somewhat common.

Unfortunately, I have no idea how to fix the QSocketNotifier stuff. Maybe you'll have to run your own version of it?

Yeah, I will figure something out.

KT probably closed it, but the actual socket has not yet been removed from the list.

I haven't looked at the code in excruciating detail, but I'm not sure how thats possible. Should the class not be removed asap upon closure?

poll has a timeout like select, but things certainly need to be tweaked.

Hmm, I've never used poll myself, I always just assumed it immediately returned once its scanned the sockets you gave it. Instead of sitting waiting for data, or a timeout. Meaning the programmer has to sit in a loop calling poll (that is what POLL means...) to see if theres any activity.

Tomasu wrote:

KT probably closed it, but the actual socket has not yet been removed from the list.

I haven't looked at the code in excruciating detail, but I'm not sure how thats possible. Should the class not be removed asap upon closure?

Well no, removing and monitoring is done in 2 threads, so to avoid problems, things are protected with a mutex. Which can lead to the remove code having to wait until the monitoring code has finished.

Hmm, I've never used poll myself, I always just assumed it immediately returned once its scanned the sockets you gave it. Instead of sitting waiting for data, or a timeout. Meaning the programmer has to sit in a loop calling poll (that is what POLL means...) to see if theres any activity.

Well, unix system calls can be a bit weirdly named, the system call to send a signal to a process is named kill. Not every signal will kill a process.

The only real difference between select and poll, is that select places a limit on the number of file descriptors.

Anyway I have now committed the code, the monitoring thread has now been split in two threads. One for upload and one for download.

The changes should result in faster speeds on LANs and faster internet connections (up to 6 MB/s).

So far so good. I really like the new categories

The crashes are gone, a SVN version hasn't had a single crash since yesterday. Thanks guys! This really saves me an enourmous amount of trouble.