Re: What about kqueue and netgraph?

[Julian Elischer <julian@xxxxxxxxxxxx>]

Richard Coleman wrote:
> Matt,
>
> Given the message passing design, and the work on libcr, what will
> be the affect on interfaces like kqueue and netgraph?  Given the
> push to asynchronous messages, doesn't that change the style of
> programming so that these interfaces are no longer preferable?  Or
> will only the underlying code change?
>
> Richard Coleman

Netgraph (in 5.x) uses an framework that already is almost completely 
complient with the logic that Matt descibed (as I read it).
(though it is mbuf based)

Basically messages come in and if the node in question can be locked
(there are reader/writer locks on every node) then it will directly call the
input method. If the lock is not achievable (or there is something already 
queued ahead of it), then the message will be queued for later processing by
"someone else" where someone else is "whoever has the lock".
(This could be done by a daemon, but at present, the code that calls
the input method will check fore more queued data when finishing)

Messages that are pure data and do not affect the node take a reader lock
and more than one may be traversing a node at a time (in SMP) but
control messages (that may affect the nodes connection with the net)
need to take a writer lock. Only one writer lock may be taken out at any 
time. (A node may specify if data messages can be allowed to only take
reader locks or whether internal processing algorythms require that they
take a stricter "writer lock". Writer locks obviously also exclude readers, 
and the rpresence of any readers will inhibit a writer. Queueing order is 
preserved.