On Thu, 21 Apr 2011 11:50:25 -0700 Rebecca Schultz Zavin rebecca@android.com wrote:
On Thu, Apr 21, 2011 at 8:14 AM, Jesse Barnes jbarnes@virtuousgeek.orgwrote:
On Thu, 21 Apr 2011 16:09:46 +0100 Tom Cooksey Tom.Cooksey@arm.com wrote:
Client apps also have to worry about the fd count, since depending on the app and object caching policy it's very easy to get over 1024 objects. But the solutions above may work for that case as well; I don't expect many apps rely on select(), and those that do can fairly easily be converted.
Though presumably not if you only have an fd for buffers you want to share with another process or device? I think the common case is you don't want to share a texture or command buffer or whatever with another process, so most of the objects don't need an fd?
Oh sure, if you don't actually allocate fds for the objects, then there's no issue. But I think the ION proposal created fds for mapped objects as well? That count could get pretty high...
That's lazy programmer (me) wanting to be able to mmap at an offset and not wanting to implement all of mmap in an ioctl. Anyway I think you can map them and then close them, wouldn't that allow you to recycle the fd?
Yeah, I think that would work fine.