Alo Sarv
lead developer

Donate via

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

Tuesday, April 26, 2005

Canceling, ServerList::connect() fixes, safeDelete()

Yesterday was filled we lengthy discussions with our designer on the philosophical aspects behind hydranode, it's features, future directions and so on. We arrived at several important conclusions, found a number of good "words" on which to build further "hydranode theme". I will not go into further details at this time though, since the ideas and philosophies still need some fine-tuning and polishing...

Today, however, I finally got a day off from design-related stuff, and got to get some coding done. One of the important issues that had been open for a long time was download canceling - canceling by name was cumbersome, and didn't quite work at all, so I implemented canceling by ID instead (in shell), which operates just as with search results - `cancel 3` cancels 3rd download in `view downloads` listing.

The new canceling code, however, brought up another issue that we had tried to fix for long time, but never really got fixed - crashes on download destruction. But since the canceling code exposed the bug more clearly than any previous times, the reasons behind the bug became obvious, while the fix needed some thought still. The issue itself was simple - when PartData emitted EVT_DESTROY event, SharedFile handled the event, and deleted the PartData object. However, other code handled the event aswell - namely, ED2K module, DownloadList class. The problem is, if SharedFile event handler is called before DownloadList handler, PartData gets deleted, and DownloadList gets event from invalid pointer, leading to crash later, deep in Client class destructors.

Originally, it was fixed by using FILO (first-in last-out) ordering in event handlers (since SharedFile is the first class to add handler for PartData), however, this doesn't work when dealing with AllHandler concept (add handler for all objects of same type) - AllHandler is called AFTER normal event handlers, and that's what DownloadList was doing. Changing AllHandler to be called before other handlers would'v been just as error-prone as current way, since it would create the same problem, only reversed, possibly in some other context. A more generic solution was needed.

Obviously, this problem only appears when dealing with object destruction, so logically, the solution would be to ensure that the object gets deleted at the end of event loop, when all pending events have been handled. Hence, EventTable::safeDelete() method was implemented, which schedules the object for destruction, and at the end of event loop, the object is actually deleted.


On other news, command handling in Shell was improved today; now all commands can be abbrevated as much as is needed to resolve ambiguouties. For example, `s` is ambiguous - 'search' or 'shutdown', while `se` already resolves to `search`. Also, commands are now initially sent to current object, and only if that fails, global commands are handled. Ambiguoutiy resolution is still limited to one at a time, thus in serverlist/ dir, `c` resolves to 'connect', instead of giving ambiguouty between 'connect' and 'cancel'.

Network downtimes are now also handled more gracefully in hydranode; crashes in ServerList::connect() have been fixed (again a long-time bug, with 4 reports in tracker associated with it). While servers are still dropped from serverlist due to failed attempts, it is guaranteed that at least two hard-coded servers always remain in list at all times.

Madcat, ZzZz

the option of marking servers prefered and/or working by the user could help making the decision of what servers to drop easier
Yes, but that puts work on the user, work that the application should do FOR the user. User cannot be expected to know how to do it, know what servers are stable, and so on. User wants to search and download, not go around and mark servers "working".

We'll, I'd like to specify my favourites, that HN should try to stay connected to.
we can put a score sstem to connect to server, , all start with 10 points, if fail lose 10 points , if connect won the number of users *0,01 of points, and go on....
Post a Comment

<< Home

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