Re: Kalloc and lck_mtx_lock
Re: Kalloc and lck_mtx_lock
- Subject: Re: Kalloc and lck_mtx_lock
- From: Greg <email@hidden>
- Date: Tue, 23 Jun 2009 23:13:50 -0400
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?
Best,
- Greg
On Jun 23, 2009, at 10:53 PM, Michael Smith wrote:
On Jun 23, 2009, at 6:27 PM, Greg wrote:
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?
Greg,
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.
I know I'm going to regret this. 8)
= Mike
--
Ars longa, vita brevis, occasio praeceps, experimentum periculosum,
iudicium difficile -- Hippocrates
_______________________________________________
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