Why have splr semantics? That is, it raises to splsoftclock if current
priority is lower, else doesn't fiddle with it.
On Fri, 25 Jun 1999, Justin T. Gibbs wrote:
> I've come across several instances where I need to fiddle with state that
> is also touched by a timeout handler. From a naming standpoint,
> splsoftclock() sounds like the correct spl routine to use for protecting
> these activities. Unfortunately this only holds true if splsoftclock()
> is used in a process context where the fact that it may actually lower
> the ipl to softclock is not an issue. As it currently stands, in most
> cases you can rely on the fact that any spl level will also block callouts,
> but this seems risky. What I'd like to see happen is for either the
> semantics of splsoftclock() to change, or to have a new spl introduced
> (splcallout()??). The hope is to provide a consistent interface across
> all *BSDs which is why I've addressed this to all of the *BSD projects.
> I look forward to you input on this proposal.
>
> --
> Justin
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
