Almost everything in dclib is run on one thread, an extra thread is only used for: filelist refresh, some hublist parsing, and one permanently waiting for dns lookups.
Making dclib go faster on multi-core CPUs is not the issue, the problem is that doing anything e.g. compress, encrypt, hash data as it is transferred will be blocking other things.
There are however, mutexes everywhere, ensuring things are only accessed by one thread at once. Presumably the dclib thread and the gui thread.
I am actually quite surprised that anything manages to work at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-11-26
Hello Edward,
> I am actually quite surprised that anything manages to work at all.
Sure ;-) Remember the plugin interface ...
Im quite surprised why you change a standalone library to a big (i need all) library thing. The main goal for dclib was to be small and manage almost all related to the dc-protocol. At my start and end point there was no QT4 if you can remember. The object control-transfer from the gui to/from dclib based on a simple free way of communication. With that you have the power to run a standalone dclib on a remote computer and control it over the network with the gui or whatever.
Anyway good work and good luck.
Regards,
Mathias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was not intending to make dclib bigger, although many changes also did. It now uses some STL classes, this did not achieve much, and wasn't finished. Also iconv is required, seems necessary.
I also never finished re-writing the QT4 edition to not use the Qt3Support library, which drags in many other libraries.
The surprising thing should have referred to dclib working fine even though it does each hub, then each transfer, one at a time, although most of the code to make it work with more threads is probably already there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Almost everything in dclib is run on one thread, an extra thread is only used for: filelist refresh, some hublist parsing, and one permanently waiting for dns lookups.
Making dclib go faster on multi-core CPUs is not the issue, the problem is that doing anything e.g. compress, encrypt, hash data as it is transferred will be blocking other things.
There are however, mutexes everywhere, ensuring things are only accessed by one thread at once. Presumably the dclib thread and the gui thread.
I am actually quite surprised that anything manages to work at all.
Hello Edward,
> I am actually quite surprised that anything manages to work at all.
Sure ;-) Remember the plugin interface ...
Im quite surprised why you change a standalone library to a big (i need all) library thing. The main goal for dclib was to be small and manage almost all related to the dc-protocol. At my start and end point there was no QT4 if you can remember. The object control-transfer from the gui to/from dclib based on a simple free way of communication. With that you have the power to run a standalone dclib on a remote computer and control it over the network with the gui or whatever.
Anyway good work and good luck.
Regards,
Mathias
Hello Mathias!
I was not intending to make dclib bigger, although many changes also did. It now uses some STL classes, this did not achieve much, and wasn't finished. Also iconv is required, seems necessary.
I also never finished re-writing the QT4 edition to not use the Qt3Support library, which drags in many other libraries.
The surprising thing should have referred to dclib working fine even though it does each hub, then each transfer, one at a time, although most of the code to make it work with more threads is probably already there.