On 5 February 2016 at 14:25, Pekka Paalanen wrote:
> On Fri, 5 Feb 2016 14:44:29 +0100
> Rui Matos wrote:
>
>> Keeping the shm fd open beyond pixmap creation means we can easily
>> reach the open file descriptor limit if an X client asks us to create
>> that many pixmaps. Instead, let's get the
> > > [...]
> > >
> > > the idea here looks fine to me.
> > >
> > > However, I've been wondering, surely there was a reason why it wasn't
> > > coded like this in the first place?
> > >
> > > Could you check if this patch causes Xwayland to create lots of
> > > wl_buffers it will never attach an
- Original Message -
> Hi all,
>
> - Original Message -
> > On Fri, 5 Feb 2016 14:44:29 +0100
> > Rui Matos wrote:
> >
> > > Keeping the shm fd open beyond pixmap creation means we can easily
> > > reach the open file descriptor limit if an X client asks us to create
> > > that
Hi all,
- Original Message -
> On Fri, 5 Feb 2016 14:44:29 +0100
> Rui Matos wrote:
>
> > Keeping the shm fd open beyond pixmap creation means we can easily
> > reach the open file descriptor limit if an X client asks us to create
> > that many pixmaps. Instead, let's get the wl_buffer
On Fri, 5 Feb 2016 14:44:29 +0100
Rui Matos wrote:
> Keeping the shm fd open beyond pixmap creation means we can easily
> reach the open file descriptor limit if an X client asks us to create
> that many pixmaps. Instead, let's get the wl_buffer immediatly so that
> we can destroy the shm pool a
Keeping the shm fd open beyond pixmap creation means we can easily
reach the open file descriptor limit if an X client asks us to create
that many pixmaps. Instead, let's get the wl_buffer immediatly so that
we can destroy the shm pool and close the fd before being asked to
create more.
---
On Fri
