Not exactly perfect
Now I see why my concept wasn't all that perfect. I can't just create an event for each task cause the event-sending thread needs to lock the event. Thus, a thread will never know when someone inserted a thread and thus not when there an event to fire. However, this can be overcome by rewriting the whole system to have a taskpool for each tasker and exclusive acces to all events possibly fired by those task. But, to be honest, if you got 100 tasks and need to bind all those to a single thread, allocating a total of 200 mutexes forthem, I somehow think that the solution isn't really ressource-friendly. Um, lemme think - I'm using a mutex for every currently loaded/to be loaded ressource in the game, thus potentially creating a huge pool. If I do now add another bunch of mutexes, I'll have several hundrets of mutexes. This is quite a lot, simply too much if you ask me. So wit only one event type and one tasker per type, it should work fine enough I think. Geez, I didn't really thinkg about this. However, since I don't exactly need ressources to stay persistent all the time, I should use some sort of ressource pool to dynamically create runtime ressource structures. I know I want a ressource tree consisting of ressource pathes, their corresponding types and a ressource pointer for the current ressource task structure. This way I can dynamically take stuff from the pool until the maximum amounts of loaded ressources is reached. More complex than I thought, but I don't want to have so many synchronization objects active. Especially if I ever want to use this code for smaller platforms, namely the NXT. Also, I'm thinking about wrapping the whole threading and time interface stuff in it's own set of structures to have a unified way creating and destroying stuff. Ok, I rwally need to make a plan for all this.