I hate popping up on mailing lists without any introductions, but anyway...
I can't help feeling that you're going about this in the most complex way possible. Given that you are generating all the code from a source script at runtime, why don't you just inject code to monitor memory usage inline? Unless you are revising LSL (I'm a secondlife user) all data operations are value based, so it's pretty easy to see where memory is freed. There would be an intermediate time between the script's memory counter being decremented and the GC actually recovering that memory which would potentially allow scripts to lag the server by creating tons of garbage, but you could limit that by accounting for memory allocation events in your scheduling. btw. I'm curious as to how you are dealing with the issue of assemblies (dynamically generated or otherwise) not being unloadable? .NET is pretty badly designed for handline dynamic code in the way you'd want to for a game server. The only way you can unload code is to load that code in a seperate AppDomain and unload the AppDomain when you're done with it. Of course you can't load every script into it's own AppDomain because each has a large allocation overhead. There is also a significant marshalling overhead when calling across AppDomains. The alternative is to generate code in a single AppDomain and put up with the fact that you're going to leak memory as users load new scripts and recompile existing ones. As you need some way to serialize script state anyway, I guess you could serialize all the scripts periodically and unload the AppDomain and start again. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list