Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Monday, January 31, 2005

Finalizing and regress-testing new Hasher

Caught cold yesterday (stupid winter), so been rather ill (explaining last night's missing blog post), however, today things started looking better, so got some active development done.

The major topic of today was the new hasher - yes, the 130-line one. After lot of testing, fixing and more testing, the thing seems stable now. Had some trouble with getting all the locks properly handled, even found a bug in main event loop which caused some events handling to be delayed until next event was submitted - something that made little difference in main app runtime, but broke my hasher test-app.

After adding some statistics code (again) to hasher, I realized that my original idea of sleeping + reading was still fundamentally flawed - the performance drop from sleeping is significent, even on 2.6 kernel systems - 5MB/s vs 15MB/s. So, now hasher will be running at max speed at all times, and we'll just have to patch Boost.Thread lib at some point to get thread priorities support (which it doesn't support right now, which in turn was the reason why I wanted to test out the sleeping system in the first place). However, it's highly unlikely I'll get around to do that in near future - still have work to do on PartData and friends.

Another interesting question is wtf to do with enums. See - I'v been using enums for events since the very beginning, because they are simply most convenient data types for that. Example:

enum MyEvent { EVT_DESTROY = 0; };
void onEvent(Source *src, MyEvent evt);


However, the enums come with one major problem - enum's can't be forward declared. Yes, I'm aware MSVC, as well as several other compiles support it, however, ISO C++ standard says they cannot be forward declared - simply some compilers implement it anyway as an extension. GCC, however, being most standard-compliant compiler around the block, does not implement it as an extension, so using enums for events creates a damned big header inter-dependancy problem. This only affects compile-time, but it's still not very nice to need to include tons of crap just because enums can't be forward-declared :(

Madcat, ZzZz



Comments:
About the enums, why not simply have a header file declaring the most frequently used enums (e.g. events), and include it in the needed source files? Should not slow down compile time by much imo (as you won't have the classes definitions together w/ the enums). -Avi
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?