--vmttodhTwj0NAgWp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Mar 31, 2004 at 12:41:28PM +0200, Hubert Feyrer wrote:
> They key seems to be keeping/having/storing enough state that the function
> called upon return can continue where it left off before the call.

In case it helps anyone else, my "oh, so that's what it's all about"
moment came when I thought of them like Java events and listener
interfaces.  A Java class implements the listener interface and
registers to be notified of an event via a callback to one of its
methods when the event fires.

As you say, storing state (so there's something to continue) is the
key. In the Java case, the relevant state is encapsulated in the
object whose method is called.  In C for the NetBSD kernel, you don't
have the implicit "this." reference, so you need to store the relevant
state in a struct somewhere explicit and arrange to have a reference
to that passed back to you in the callback argument.  This might be
something like the pcb for tcp stack timeout events, for example.

(In Java you are often passed and event object with some considerable
details of what happened to a generic event handler method, with
kconts in C this seems to look like a separate registered callback for
each event type).

I suspect kconts are most useful for building an event-driven
framework in the kernel, though they could probably be used for other
things too.  Within such a framework, the kconts themselves might not
be immediately visible to, say, a typical driver writer - he just
needs to register and handle the relevant N event types for his
device.

One of the potentially interesting events to listen for would be the
release of a lock you were unable to take; contenders for the lock
could queue up waiting for it and be called back in turn to retry.

Another possibility is for object cleanup via reference counting, with
a callback when the last holder of an item is finished with it.  This
might let us build something like the RCU mechanism linux adoped from
sequent.

--
Dan.
--vmttodhTwj0NAgWp
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFAarEKEAVxvV4N66cRAjJFAJ9eRwSRTrP7sKHFH0+EnEELuMxvAACfZEYZ
jhBXaGIix6M4LrkjSivdLIQ=
=5wVc
-----END PGP SIGNATURE-----

--vmttodhTwj0NAgWp--