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, December 14, 2004

Rewriting events

Madcat begins some strange incantations...
Madcat utters the words 'optimize desktop'
Madcat's spell backfires, and he squales in surprise.
Madcat smirks as his desktop explodes in his face.
Madcat curses and swears for a long time.
Madcat mumbles 'god I hate when that spell backfires'

(Sorry, inside joke :P)

Anyway, been getting reaquinted with windows IDE's and been cursing and swearing at them most of the time. One IDE has nice editor, other one has better compiler integration, third one is simply perfect, except for a bunch of bugs ... *curses*. Beginning to remember what it meant to develop things on win32 ... amazing how fast you forget this stuff.

So anyway, as noted previously, the major obstacle in hydranode/win32 is the event subsystem, which uses 10-yr-old library as backend. So I headed down to event subsystem, and rewrote the main engine using Boost.Signals library backend. That was the (relativly) easy part - altough it still needs more testing (and deployment over the existing codebase *cough**cough*), that's nothing hard. What's complex is figuring out how get the new system better than the old one (which was the second major reason for rewriting it anyway).

The main issue here is that I'd like to decouple the event source and the event table. In legacy event systems, event sources are tightly coupled with the event tables, and as such define how events can be procesed. For example, the event source defines what kind of events it can emit. However, sometimes I don't want to emit the event FROM the event source class, but from outside. For example:
HashWork *hw = new HashWork(myfile);
HashWork::getEventTable().postEvent(hw, NEW_JOB);

In this case, the event isn't emitted from the HashWork class itself, but from somewhere outside. Current Event subsystem implementation allows it, and new one (already) allows it too, however, it's still not as flexible as needed, since HashWork object in this case still needs to declare an event table, with predefined event handler prototype. What if I wanted to post a std::string type event instead ? I couldn't, since HashWork's event table wouldn't accept the event.

The idea is to use free functions for posting/adding handlers, then use Singleton event tables, which those free functions access, one per each object type. This way, we can write:
HashWork *hw = new HashWork(myfile);
postEvent(hw, NEW_JOB); // instanciates EventTable < HashWork*, int > event table and posts
postEvent(hw, "Doh"); // instanciates EventTable < boost::shared_ptr < HashWork > , const char* > event table and posts

This is already achieved, however, one last problem remains. How do we handle the situation, where the object is wrapped in Boost.SmartPtr wrapper ? My current tests have shown that it's not achievable (in a generic manner) to use boost::shared_ptr-wrapped objects with event tables, however, boost::intrusive_ptr-wrapped are theoretically possible. The problem however is, how do we mix the events posted from inside the object with events posted from outside? Because when posting from inside, it would go to EventTable < object*,EventType > table (because it uses this to aquire the pointer to itself), however, when posting from outside, it would go to EventTable < boost::intrusive_ptr < object > , EventType > table instead ... *ponders*


Comments: Post a Comment

<< Home

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