site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -josh On Feb 3, 2006, at 7:15 AM, Stephane Sudre wrote: OK, so this would not explain a recursive lock attempt. On 2 févr. 06, at 20:29, Josh Graessley wrote: -josh On Feb 2, 2006, at 9:36 AM, Stephane Sudre wrote: Maybe someone can shed some light on this. the callback can be sum-up to: myCallBack { mutex lock do something but never return anything mutex unlock return a value } Question: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/jgraessley%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/jgraessley%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com As currently implemented, the iff_input callback is most likely to occur on the dlil input thread. Your callback for handling data sent on a kernel control socket will occur on the thread that calls send/ sendmsg/sendto. These are two different threads. The implementation may change in the future. You need to be very careful. One day there may be multiple input threads. Other changes are possible too. Too avoid headaches, you need to be very careful with your locking. Lock only while manipulating shared data structures. Never hold a lock while calling back in to the stack, you never know when the stack might turn around and call your kext. While using sockets inside of the kernel, never close the socket while another thread may be performing an operation on that socket (send/ recv/sockopt). Also, be very conscious of the performance impact of your kext. netperf is a decent tool for testing throughput. As you develop your kext, try running netperf with and without your kext to see what impact you're having. Gigabit is pretty dang fast, and 10 gigabit is just ridiculously fast. It doesn't take much to hose your throughput on networks running at those speeds. 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? 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. 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. now at one point an interface is going away => a detach filter is called. can the detach filter (iflt_detach) be called while we are in myCallBack? This email sent to jgraessley@apple.com This email sent to jgraessley@apple.com smime.p7s