RE: I thought audio processing threads weren't supposed to call malloc
RE: I thought audio processing threads weren't supposed to call malloc
- Subject: RE: I thought audio processing threads weren't supposed to call malloc
- From: Steven Clark <email@hidden>
- Date: Mon, 22 Dec 2014 22:51:36 +0000
- Thread-topic: I thought audio processing threads weren't supposed to call malloc
A couple years ago I looked at (googled) recent developments in memory management because I thought I’d heard that free() was the bugaboo, not malloc() – and
as long as you don’t have to call brk() that seemed to be true for modern implementations. Brk() doesn’t affect asymptotic behavior because either your program grows infinitely and therefore has no asymptotic behavior, or it reaches a point after which it
no longer needs to call brk(). (Don’t you just love academic thinking?)
I think I also specifically looked up gcc’s malloc/free implementation, but I’m not sure. I am sure I didn’t chase down clang’s.
Steven J. Clark
VGo Communications
From: Paul Davis [mailto:email@hidden]
Sent: Monday, December 22, 2014 5:32 PM
To: Steven Clark
Cc: Taylor Holliday; CoreAudio API
Subject: Re: I thought audio processing threads weren't supposed to call malloc
On Mon, Dec 22, 2014 at 5:23 PM, Steven Clark <email@hidden> wrote:
It doesn’t look like this is taking place during the critical time.
indeed, some hardware property change which effectively means that audio processing is likely interrupted.
By the way, the last time I checked malloc() was actually bounded (and short) time;
if the malloc mechanism needs to call brk(2), it will not be bounded.
free() is the potential problem. And, implementations these days are pretty smart about free() too.
there are many different implementations of malloc/free, some of which are almost RT safe. i'd be extremely suprised if the one that comes with the Darwin C library meets that description, and it almost certainly doesn't avoid locks.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden