Andy Tucker wrote:
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.
Thanks Andy. I was thinking that at least if no threads were in the class,
that the system wouldn't have cause to call into the class code, or at
least not
from the a context where (if one needed to) grab adaptive locks it would
be bad.
I'll try to dig up the bug id you mentioned.
I've not actually gone down the path to see what challanges would be at
play here.
Sounds like fun though :)
-Eric
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
