In message <45E785C2.3020209@3am-software.com>, Matt Thomas writes:
>Jonathan Stone wrote:


>> I'd be happy to see generic softintr callbacks take an extra argument.
>> But that argument would be NULL for all existing, non-kcont uses.
>> That sounds like wasted verbiage to me; how about you?
>
>Is there any reason why, when a callout triggers, it wouldn't be delivered
>via a kcont?  Or if you need a softintr?

hi Matt,

I'd love to see that.  But it does (as you note below) mean adding
another NULL argument to existing callbacks for sofintr or callouts;
and adding a member to callout or softint states to hold that 2nd
callback argument, for the cases when it's not NULL.  Then (as you say
below) yes, much of the mechanism can be shared. Heck, a typedef for
holding the callback-state could be shared.


>What I am saying that callout and softintr are specific invokation of kconts.

Currently they're subsets (1 callback arg rather than 2), but yes
of course: both can be modelled with continuations.

>I see no reason why they can't all use the same mechanism for delivery?
>
>I am not saying dumb down kconts, but raising the other up.

Oh, that's exciting news. Really.

Hmmm. Now I think about it, was it you who suggested we could
just about replace softints with kconts, or merge the two?