Re: KPI Interface filter and filter detachment
Re: KPI Interface filter and filter detachment
- Subject: Re: KPI Interface filter and filter detachment
- From: Stephane Sudre <email@hidden>
- Date: Fri, 3 Feb 2006 16:15:23 +0100
OK, so this would not explain a recursive lock attempt.
Mmm, is it possible for a kernel control message to be received when
you are within a iff_input callback? I would say yes. But would it be
considered the same "thread" or not?
On 2 févr. 06, at 20:29, Josh Graessley wrote:
I believe the detach is a special case. The detach is there to notify
you that your filter has been detached. In this case, that is the last
call you will receive and it should only happen when we are not
calling any other entry points in your filter for that interface.
-josh
On Feb 2, 2006, at 9:36 AM, Stephane Sudre wrote:
Maybe someone can shed some light on this.
Let's say a KPI Interface filter is attached to every available
interfaces.
Let's say this KPI Interface filter is implementing a iff_input
callback.
the callback can be sum-up to:
myCallBack
{
mutex lock
do something but never return anything
mutex unlock
return a value
}
now at one point an interface is going away => a detach filter is
called.
Question:
can the detach filter (iflt_detach) be called while we are in
myCallBack?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden