As for your firat comment - this patch adds a lisp function to check if the xserver is responsive. It does not run automatically for everyone, so only those who are interested should call this function from their lisp configuration. Personally I added run-at-time to call the exported function from the patch.
The patch was design to not change existing behaviour of emacs. If you see somewhere this is not the case I could fix that.
I can add ifdef to make this code compile only with this specific xlib. Would that be ok in your opinion?
Secondly, the exported function gets the frame you wish to check.
Thirdly, this what I saw when I debugged it.
otadmor <otadmor@gmail.com> writes:
> When running xlb function the code gets stuck in a native endless
> loop. The patch I have added closes the fd of the xserver, which as a
> side effect ends the endless loop. Some would say this patch is
> fixing a bug of a dependency of emacs and not emacs itself (it is just
> that emacs uses it in a certain way...). This solution uses native
> timer (using signals) to detect the timeout. Upon reaching a timeout
> it closes an the fd on the same thread as the xlb code (this is
> because of how signals works).
I am not happy with your change. Firstly, it is not portable and makes
very specific assumptions about the internals of Xlib, while we support
any Xlib from X11R6 in the past to the foreseeable future, along with
some alternative implementations. We do not use any part of Xlib that
forms part of the interface for protocol extensions, since Emacs is not
an X11 protocol extension.
Secondly, Emacs supports connecting multiple X displays at the same
time. Your code does not try to support that at all.
Thirdly, I cannot understand what is returning EINTR: that error occurs
only when the read from the X connection was interrupted by a signal.
If the X server goes down (such as when your laptop goes to sleep), the
connection eventually times out and closes, which then triggers an IO
error that Emacs does handle correctly. If it does not, then that is a
bug in xcb and should be reported to their developers.
I suggest to add an entry to etc/PROBLEMS describing your specific
use case instead.
> To do this is lisp we need to answer the following:
> 1. How to find the fd of the current xserver using lisp?
That is not possible, and I wouldn't agree to such a function.
> 4. Is it even allowed to run lisp code while the main thread is in xlb
> native code (stack frame is deep inside other library and this other
> library was called from lisp).
Yes, but not inside a signal handler (unless it is an IO signal, see
block_input and friends.)