On 6/16/06, Eric Saxe <[EMAIL PROTECTED]> wrote:
Another thing to consider, the _fini() entry points in the existing modules all return EBUSY, which means that while the classes are dynamically loadable, they are also unloadable. :) That's not to say that you're scheduling class can't be, but you'll want to take the right precautions to ensure that unloading the class is "safe" (like ensuring no threads are in your class, etc).
Can't be done (safely), the framework itself is racy. Although you can ensure that there are not threads in the class you can't protect against something calling into the class code. Unless something has changed in this area recently. There's some ancient bug on this but I don't remember the number. Then again, if this is just for fun/experiment it's probably fine to keep a busy count and allow the class to be unloaded when it's not in use - you'll be OK as long as something isn't calling into the class at the same time you're unloading it. To the original poster, I'd suggest starting with an existing class (like FX) and modifying it as needed. Or just write a user level scheduler that modifies FX priorities and time quanta using priocntl (the easiest solution if the timing constraints aren't that tight). Andy _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
