aMule Bug Tracker - aMule
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001096aMuleSharedfilespublic2007-05-02 16:432008-02-21 22:52
Reporterpmontepagano 
Assigned ToXaignar 
PrioritynormalSeverityblockReproducibilityhave not tried
StatusresolvedResolutionwon't fix 
PlatformOSOS Version
Product Version2.1.3 
Target VersionFixed in Version 
Fixed in Revision
Operating SystemAny
Summary0001096: aMule uses up ALL resources at startup when there are many new files in the shared folder
DescriptionI have a specific folder into which I download everything from different protocols (torrent, amule, soulseek, etc). I, for instance, I don't use aMule for a week, and during that week I did many downloads, the moment I startup aMule, everything freezes, sometimes for several minutes, because aMule is exploring the new files, and producing their AICH.
This whole process is VERY I/O intensive, since it has to read all that data from the hard drive.

My proposal is the following: Can't you divide the part of the code of aMule that scans files and produces their AICH code into another process, and give it a VERY low NICE? (Or, if we are in a Windows enviroment, a low "priority") This way starting up aMule would be less painful, and new files would be added progressively.
Steps To Reproduce
Additional InformationI'm using aMule 2.1.3, on Gentoo Linux (kernel 2.6.15).
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2007-05-02 16:43pmontepaganoNew Issue
2007-05-02 16:43pmontepaganoOperating System => Any
2007-05-03 18:18KryNote Added: 0002274
2008-02-21 22:52XaignarStatusnew => resolved
2008-02-21 22:52XaignarResolutionopen => won't fix
2008-02-21 22:52XaignarAssigned To => Xaignar
2008-02-21 22:52XaignarNote Added: 0002637

Notes
(0002274)
Kry   
2007-05-03 18:18   
The hashing is already done on a thread and with the lowest priority.
(0002637)
Xaignar   
2008-02-21 22:52   
I'm marking this as "won't fix". As Kry pointed out, we already give the relevant thread the lowest possible priority, and moving the task to a seperate problem would just complicate the issue even further, and not help that much, as this is an issue of IO-scheduling rather than CPU-scheduling.