[PULL wayland] fd leak checks and a socket fallback
ppaalanen at gmail.com
Mon Apr 23 05:44:16 PDT 2012
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
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?
More information about the wayland-devel