site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com void *my_malloc(int size, char *tag) { lock(); //calls semaphore_wait internally //get memory unlock(); } Notice, I am not checking the result of lock. Is my reasoning correct ie. consistent with how darwin works ? You are doing this wrong. -- Terry _______________________________________________ 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... On Mar 18, 2008, at 1:33 AM, Ratheesh Ramachandran wrote: My thinking is that this is not a "regular" bad access scenario. But, something getting triggered by thread-safety issues (ie. the semaphore_wait's KERN_ABORTED error). I have a memory allocator function which looks something like this: If somebody does a thread_terminate() on one of the threads waiting on lock, thread-safety is compromised ie, multiple threads may access the critical section. The memory allocator may assign the same chunk of memory to different threads, one of them may free it, crashing the others. What is the best way to handle such a situation ? Should my_malloc() have returned if lock() returned a KERN_ABORTED ? Should it have retried ? Will KERN_ABORTED always imply thread termination ? See execargs_alloc in xnu in bsd/kern/kern_exec.c for an example of how to do an allocation using semaphore_wait() without breaking. Alternately, indicate that your thread us uninterruptible until it gets the lock (and make sure that you _get_ the lock sometime, or you will block forever -- better to just do it right). This email sent to site_archiver@lists.apple.com