[PULL wayland] fd leak checks and a socket fallback

[Pekka Paalanen]

On Mon, 23 Apr 2012 14:10 +0200
Thiago Macieira <thiago.macieira at intel.com> wrote:

> On segunda-feira, 23 de abril de 2012 11.22.16, Pekka Paalanen wrote:
> > > PS: if you're reading this and you want to run Wayland on your non-Linux 
> > > system, you should also add those to your OS. Yesterday.
> > 
> > Hi Thiago,
> > 
> > you speak with the voice of reason. Unfortunately, I doubt reason or
> > sanity is something to be strongly associated with Android. I'm not
> > ready take on such battle for now.
> 
> Well, they said that bionic was a stripped-down version of libc, sometimes 
> deviating from POSIX, and it would only be used to support Android's own 
> needs.

Derived from some BSD libc, IIUC, which missed linuxisms to begin with.

> However, since Android is heavily based on Java, which in turn encourages the 
> use of threads for everything, I really can't see how they can write the C 
> backends for those libraries without the thread-safe system calls. In fact, I 
> was quite surprised no one had thought of that before Ulrich Drepper came up 
> with them back in 2008.

I don't think they use much of the POSIX-like functions, since they have
binder. And binder depends heavily on threads.

I probably don't want to know how they manage... and I have been able to
avoid binder so far.

> In any case, while on Linux, the constants are cross-architecture, so you can 
> #define them if they weren't before. If the libc doesn't provide the system 
> calls, there are workarounds:
> 
>  1) open & socket - no new system call required, just a new constant
>  2) dup3 - just use F_DUPFD_CLOEXEC, which we do in Wayland
>  3) pipe2, accept4, eventfd2, epoll_create1, etc. - can use syscall:
> 	syscall(__NR_accept4, fd, &addr, &addrlen, SOCK_CLOEXEC);
> 
> Option 3 is unavailable if bionic doesn't provide the syscall(3) function. I'd 
> say that writing assembly to make the system call is above the pain threshold 
> for solving this particular issue. In that case, we can point the finger at 
> them and say "it's not thread-safe and it's entirely your fault".

Thanks for the advice.

syscall(2) seems to be there, but I won't go as far as 3) yet. I'm
probably going a bit too far for a proof-of-concept already. I hope it
is better to have even half-assed fallbacks in upstream Wayland
than burying them in our private branches.

Btw. I can't find a definition for __NR_accept4 in Bionic. __NR_accept
is there. Are those constants between arches, would I be able to
#define it myself?


Thanks,
pq