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 protected]] 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 protected]<mailto:[email protected]>> 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; how did you check this? 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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
