This is my personal take on this only; I don't speak for other Android platform developers. I'm also not familiar with surfaceflinger in particular, so can't speak to this specific bug.
I'm happy to use mutexes within a process, but find mutexes between processes rather distasteful (yet occasionally necessary). For example, AudioFlinger shares a mutex with each AudioTrack client, and locks via a try-lock for protection in case the client blocks indefinitely. AudioFlinger also uses binder death notifications to detect when clients exit. The try-lock mutex code is fragile, and I would prefer a different mechanism that's more resilient. I think that if a system component is getting hung up when an app process dies, it might indicate a higher-level IPC mechanism is needed for recovery, such as the binder death notification. To me, the idea of "robust futexes" sounds like applying a fragile repair to an already fragile mechanism [mutexes used between processes]. Can you provide more details on the specific bug you're seeing? I can then forward it to the experts in that area. On Tuesday, May 15, 2012 4:33:22 AM UTC-7, Suman Saraf wrote: > > Hello google folks, > > Is there any plan to bring robust futexes support to bionic so that held > locks are cleared when processes die? > > I am seeing surfaceflinger hanging on some such locks when some boot > intent receivers die (not so gracefully). I just wanted to know if anything > like this is planned or should I peek at glibc and do similar handling in > bionic? > > Thanks > Suman > > > > > > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
