When I try to select a torrent with more than 1024 files (why so many? I don't know), ktorrent complains that it has too many open files.

So I went to change my ulimit. I don't know of an easier way than to become root, change it there, have that shell become myself again, reset DISPLAY, and then launch ktorrent. Kinda painful. But if that was all that it was, I wouldn't complain.

I then get this message:

Code: Select all

QSocketNotifier: Socket descriptor too large for select()
QSocketNotifier: Internal error


I suspect that someone isn't ready to handle that many open files anyway.

It wouldn't surprise me to learn that Qt (or KDE) had a filehandle manager type of container or something to use (although I wouldn't know where to look if it does) where filehandles get automatically reused, while the opaque handles that your app uses will close/open handles and seek to positions to continue using them. If there is such a beast, perhaps KT would be an ideal candidate for using such a class

PS: I'm running from SVN at the absolute latest as of now - revision 538342.

It looks like a problem with FD_SETSIZE in compile time.

Tanktalus wrote:When I try to select a torrent with more than 1024 files (why so many? I don't know), ktorrent complains that it has too many open files.

So I went to change my ulimit. I don't know of an easier way than to become root, change it there, have that shell become myself again, reset DISPLAY, and then launch ktorrent. Kinda painful. But if that was all that it was, I wouldn't complain.

I then get this message:

Code: Select all

QSocketNotifier: Socket descriptor too large for select()
QSocketNotifier: Internal error


I suspect that someone isn't ready to handle that many open files anyway.

It wouldn't surprise me to learn that Qt (or KDE) had a filehandle manager type of container or something to use (although I wouldn't know where to look if it does) where filehandles get automatically reused, while the opaque handles that your app uses will close/open handles and seek to positions to continue using them. If there is such a beast, perhaps KT would be an ideal candidate for using such a class

PS: I'm running from SVN at the absolute latest as of now - revision 538342.

Each network connection is also a file, and we only open files on disk when absolutely necessary.

And this :
QSocketNotifier: Socket descriptor too large for select()

Hmm, maybe we are hitting some limits here in Qt's network classes.

How many other torrents are you running ?

George wrote:Hmm, maybe we are hitting some limits here in Qt's network classes.

How many other torrents are you running ?

At the time I was doing that, I had one other torrent running. I also had one stopped (incomplete), and 7 complete (and stopped) torrents also sitting around. Although I doubt that these have anything to do with it, I'll let you make that call about what information is relevant.

Tanktalus wrote:

George wrote:Hmm, maybe we are hitting some limits here in Qt's network classes.

How many other torrents are you running ?

At the time I was doing that, I had one other torrent running. I also had one stopped (incomplete), and 7 complete (and stopped) torrents also sitting around. Although I doubt that these have anything to do with it, I'll let you make that call about what information is relevant.

Stopped torrent normally do not have open files.

Could you send this torrent with the huge number of files to me, so I can test it myself ?

As per my other thread, I did a search on "d20" on bittorrent.com. On page 3, there is a Ragnarok torrent with over 3000 files. The problem occurs with that one (I'm just guessing at the 1024-file limit).

It seems that the problem occurs during preallocation of the files.

I'll take a look.

UDPATE: We got to close the files when we preallocated them. This is now done and torrents works fine,allthough a bit slow.