Re: AudioUnit plugin vs. GarageBand sandboxing
Re: AudioUnit plugin vs. GarageBand sandboxing
- Subject: Re: AudioUnit plugin vs. GarageBand sandboxing
- From: Jeremy Friesner <email@hidden>
- Date: Fri, 10 Apr 2015 21:07:28 -0700
> On Apr 10, 2015, at 8:38 PM, Christian Rober <email@hidden> wrote:
>
> Nicely done sir!
Thanks :)
> Yeah... the man page for pthread_rwlockatt_setspshared says that PTHREAD_PROCESS_SHARED is not supported under the BUGS section (i'm on 10.9.5 too). That's a shame. :(
Ah, right — that would explain why I couldn’t get it to work. :(
> I also could not find the man page for pthread_mutexattr_setspshared. After a quick google search, it seems that the kernel may not REALLY implement that function. You may not be getting the protection you expect, though I hope you are!
I tested it with a little torture test (where I have several processes locking the mutex, writing to the shared memory area, reading back what they wrote, then unlocking it again, in an endless loop). With the pthread_mutexattr_setpshared() call in place, the test proceeds as expected. If I comment out the pthread_mutexattr_setpshared() call, the processes all hang/deadlock as soon as I start the second one. So it appears that the call is functional and necessary.
> One small thing, I think your 2nd call to open will return EEXIST if there is a race and you lost to your other process. My understanding is that create is "atomic", within kernel and with respect to the file descriptors. In a create race condition one will fail and one will succeed (assuming all else is sound). You may want to check errno in that case, but this race is probably super rare, if it exists at all.
You’re right, I will add some code to handle that possibility. Thanks!
Jeremy
_______________________________________________
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