site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Dec 13, 2005, at 9:44 AM, Josh Graessley wrote: Thanks, Ryan On Dec 12, 2005, at 10:23 PM, Ryan McGann wrote: This email sent to jgraessley@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... It's not that you can't block in your data in filter. You want to be careful about what you block on and how long it is likely to be blocked. For example, if you were to take a lock where you enqueue data and then drop it, that would be fine as long as the only other code taking the lock is something that takes the lock to dequeue the data so it can process it after dropping the lock. Thanks for this clarrification Josh. I don't feel so bad now taking the lock, since it should never be locked for more than a couple milliseconds (worse case). It still would be nice to have a trylock though. An example of a bad place to block would be writing the data out another socket to a user process and waiting for a response. Another bad example would be attempting to take a lock that some other piece of code holds while calling in to the network stack to perform an operation that may block. You need to evaluate the other places where the lock you will be taking is held and make sure that lock isn't held while some other long term or interdependent operation is performed. Doing so may lead to deadlocks. I take the lock inside of dataIn and dataOut to protect access to my queue of buffered data. I take it also when I need to reinject the code. As long as sock_reinject_* doesn't block, all of the statements you made about my code should hold. Basically I need to do the same thing as the tcplognke sample, and I see that sample takes a mutex inside of dataIn as well. I don't feel bad now :-) The new Tiger locking KPIs seem to lack a trylock variant for any of the lock types (mutex, spinlock, read/write). I'm trying to figure out how to get around this. I need to take a read-write lock in a socket filter dataIn callback, but of course you cannot block inside dataIn for any length of time. So I _was_ going to use a trylock, and if I failed to get the lock, just bail out. But it looks like the only way to accomplish what I want to do is to use lck_rw_sleep_deadline. However I'm not exactly sure of the semantics of this API. If I give it a deadline of "now", will it still perform a context switch regardless of whether the lock is taken or not? I don't want the expense of a context switch if the lock isn't even going to be taken. Is there any way of duplicating the behavior of a trylock using the Tiger KPIs? Or am I stuck using lck_rw_sleep_deadline? And can that API context switch on me without taking the lock? Thanks, Ryan rmcgann@mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jgraessley% 40apple.com This email sent to site_archiver@lists.apple.com