-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jusa Saari wrote: > No, this is a bug. A design bug perhaps, but still a bug. The question is, > can it be solved at this time ? After all, getting rid of threads usually > means asynchronous IO, and that is both difficult, labor-intensive, and > error-prone. Still, just because fixing a bug is difficult or impossible > doesn't mean it isn't a bug.
If most of the threads belong to requests/inserts, we can get rid of them by converting requests and inserts into state machines - see my simulation code for an idea of how this might work. If the threads belong to transfers (BlockTransmitter), getting rid of them would be more difficult. We could make PeerNode responsible for all packets sent to the peer - transfers, searches, keepalives, etc. However, this would introduce extra complexity as PeerNode would have to interleave transfers and searches - a 32 kB transfer can easily take several seconds, so we can't allow it to block other traffic. Matthew and I discussed some ideas for interleaving transfers and searches: one possibility is to have a "fast queue" for searches etc, and a separate "slow queue" for each transfer. When assembling a packet, PeerNode takes one message from the fast queue, then if there's space left in the packet it takes one message from the current slow queue (the slow queues are processed in round-robin order). Then it fills any remaining space with messages from the fast queue. This ensures that neither searches nor transfers starve, as long as messages in the fast queue are generally small enough to share a packet with a 1 kB transfer message. This is currently OK because most search messages are small, but in the future if we want to put large messages in the fast queue (eg for one-to-one streams), we'll have to rethink this. > Since no one seems to be able to figure out where the 1000 threads are > coming from, I'd say that the current system is impossible to debug ;). Hardly impossible - the person who claimed 1000 threads hasn't tried using a debugger to list the threads. Everything's impossible to debug if you won't use a debugger. ;-) Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFDSyKyua14OQlJ3sRAlZWAJ4vAw+RXbaNV7hAM3Q9VaskKQqaIgCgoAGC FYGIQYVBbNOQbdpR4wp9PTo= =Jq1G -----END PGP SIGNATURE-----
