OT: inter-process mutex (was: Re: HAL Plugin mixing streams from multiple processes)
OT: inter-process mutex (was: Re: HAL Plugin mixing streams from multiple processes)
- Subject: OT: inter-process mutex (was: Re: HAL Plugin mixing streams from multiple processes)
- From: Kieran Tyrrell <email@hidden>
- Date: Fri, 27 Aug 2010 18:20:27 +0200
Thanks Jeff,
So now I have a daemon process that's collecting the streams from the multiple driver processes, but I'm getting 'flaky' performance from mutexes in shared memory. Is pthread_mutex_t supported on OSX though shared memory with the PTHREAD_PROCESS_SHARED option? It seems to work for a considerable number of locks/unlocks, and then both (all) processes fail to get a mutex lock...
This page http://developer.apple.com/macosx/multithreadedprogramming.html suggests that maybe it's not supported, though it also states that condition variables ARE supported cross-process (with the PTHREAD_PROCESS_SHARED option) which must imply that mutexes are too (as condition variables require a mutex).
And as a final hurdle, is there any form of cross-architechure condition variable available on OSX? Our HAL driver is compiled for x86_64 and i386, and so 64bit apps open the 64bit driver and 32bit apps the 32bit driver. This makes it tricky to use fast memory mapped IPC because pthread_mutex_t and pthread_cond_t are different sizes on the different architectures...?
Thanks!
Kieran.
On 23 Aug 2010, at 21:41, Jeff Moore wrote:
>
> On Aug 23, 2010, at 12:24 PM, Kieran Tyrrell wrote:
>
>> Hi folks,
>>
>> I'm writing a HAL plugin (based on the SampleHardwarePlugin example) and everything works great until I play audio through the device from multiple processes.
>>
>> I think I misunderstood something fundamental about how the HAL devices work. I'd assumed that there was only ever one instance of the Device, and that multiple clients would appear as multiple IOProcs in the IOProcList. This is not the case, if I open iTunes and AULab for example, I get two Device instances created, each with one IOProc.
>
> Indeed. Your plug-in is instantiated in each process the HAL is initialized in. Given the myriad of ways a plug-in can go about it's business, the plug-in API itself does not put any limits on what can be done or provide any specific help in that regard.
>
>
>> What's the recommended way of dealing with handling multiple clients (processes) within a single Device? Should I be basing the driver on a .kext model instead? (AudioReflectorDriver?)
>
> It depends on whether your driver is going to be accessing real hardware or not and if it is, what interfaces the driver will use to deal with the hardware. If you already are putting a lot of code in the kernel to talk to your hardware, you might as well write an kernel driver.
>
> But if you are doing something different, the typical way that plug-ins have dealt with the cross-process problem is to create a daemon that handles managing the hardware and the plug-in in each process jus talks to the daemon to get what it needs. As I mentioned, the HAL puts no limits on how your plug-in goes about doing this. Some plug-ins just use sockets to do the cross-process communication, others use APIs like Mach messaging or other IPC APIs to handle this.
>
> --
>
> Jeff Moore
> Core Audio
> Apple
_______________________________________________
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