-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
file upload stats (lib) #107
base: master
Are you sure you want to change the base?
Conversation
|
||
uint64_t ftServer::getCumulativeUpload(RsFileHash hash) | ||
{ | ||
std::map<RsFileHash,uint64_t>::iterator it = cumulative_uploaded.find(hash) ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like a mutex is missing here.
|
||
uint64_t ftServer::getCumulativeUploadAll() | ||
{ | ||
uint64_t all = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
Make sure to always use a mutex protection when reading/writing to a std::map. Otherwise it's bound to crash when you access from different threads. Another problem is that you're not saving the upload stats. So they are lost accross restarts, which somewhat kills the entire idea since upload stats are supposed to be long-term stats. But ftServer does not have a saving system. All accounted for, it seems that it would make much more sense to store them with p3FileDatabase in ft_database.cfg.
|
when we get this stats in retroshare? we need this |
@csoler i have added before the mutex this is right or |
yes this is fine. |
I like the idea of keeping these stats. Last time I looked at it, it still needed saving that data. Of course we need to only save the stats for files that actually have been uploaded (in order to limit the file size) and using a std::map for that is indeed a good idea. |
Hi, you will reimplement this? else i can make a new pr with the mutex tonight |
new pr for this : #142 |
No description provided.