In *heavy* stress test with a large number of applications (> 7000 a
second), the manage application thread could starve the delete process
by breaking just after adding an application to the poll set.
Also, we've observed that somehow the application unregister process is
not done on most of the application by breaking the loop at each delete
from the poll set. We are still uncertain why but one theory is that
epoll detects that an I/O operation is ready (here a shutdown) and an
other subsystem of the session daemon uses that socket for I/O which
flags the poll event as "has been taken care of" thus the loop never
sees it because of that break.
The notify socket thread does not use a break between poll operation
which leads us to that conclusion with the manage apps thread.
We don't use epoll with edge-trigger thus a POLLERR/POLLHUP should
always be return as long as it's not taken care of.
Clang 3.3 with -O2 optimisations is especially picky about arithmetic
on NULL pointers. This undefined behavior is turned into optimized out
NULL checks by clang 3.3. Fix the undefined behavior by checking against
the pointer directly, without going back and forth around NULL with
pointer arithmetic.
