site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Best, - Greg On Jun 23, 2009, at 10:53 PM, Michael Smith wrote: On Jun 23, 2009, at 6:27 PM, Greg wrote: Greg, I know I'm going to regret this. 8) = Mike _______________________________________________ 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... Hmm.. my apologies, I am admittedly a little bit deficient in my understandings of the internals of the kernel, but I'm not sure as to what you mean by this: as you really don't have a good way of knowing whether your service will ultimately be depended on by code that has to run to free memory in order for the allocation to succeed. Unfortunately it would be extremely difficult (perhaps impossible), and totally out of line with KISS, for me to avoid allocating while holding a lock. One other question if I may, is it then better to call one of the malloc functions (while holding a lock) in non-blocking way (i.e. OSMalloc_noblock), or does it not matter? And if it does matter (and OSMalloc_noblock/kalloc_noblock is better), then should I take much greater caution to check for it returning NULL than if I were to use plain old OSMalloc? I've read in Amit Singh's OS X Internals book that it's not safe to call OSMalloc/kalloc while holding a "simple lock", are lck_mtx_t's therefore safe to hold when calling one of these functions? If not, then is there any way of doing so? Perhaps by using a different kind of lock or different kind of alloc function? It's generally a bad idea to call an allocation function while holding arbitrary locks, particularly if you are implementing a service, as you really don't have a good way of knowing whether your service will ultimately be depended on by code that has to run to free memory in order for the allocation to succeed. It's also very difficult to test and debug these cases, so for the most part I would encourage you simply to avoid allocating while holding any sort of lock, period. That being said, there is nothing intrinsic about mutex locks that makes it not safe to call the allocator whilst you hold one. -- Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile -- Hippocrates This email sent to site_archiver@lists.apple.com