More eventing!

Ok, I shortly before doing the actual tests whether it now FINALLY works and have to say that I'm quite nervous about it. I modified the event system to support event IDs: each event starts with number one and will increment after it happened. When listening for an event to happen, you can pass either null for the next future event or a specific event that may happen in the future (will stay in the event listener list until this will happen) or have happened in the past (in which case not waiting will be done at all). I dropped the event data because past event data can't be restored. Using increasing event IDs can be very useful for avoiding exactly those problems I had with condition variables and signal. I had to take a long way but it should pay off now. I was not able to find any problems but one that would happen in combination with a task pool when tasks get reused too recently, thus rendering threads still waiting for missed signals due to reuse and event id resets etc. Don't really want write any more about this, but I solved by using another event fired by the ressource loading functions themselves. This makes having direct task completition feedback rather useless, but I can still use it for comftable use later (don't need put the event firing code into the actual task functions). Arghh, I'm so excited. It's the only thing I can think of except using polling that could work in my project. And I'd not know what to do if it doesn't work. I mean this is for my bachelor, it HAS to damn work!

No comments: