sharplispers / clx

a fork of crhodes' fork of danb's fork of the CLX library, an X11 client for Common Lisp
Other
116 stars 46 forks source link

Documentation (or possibly behavior change) re: xlib:event-listen #89

Closed earl-ducaine closed 6 years ago

earl-ducaine commented 6 years ago

xlib:event-listen claims to block indefinitely if the local event queue is empty and timeout is nil, otherwise if the event queue is empty and timeout is not nil, it waits timeout number of seconds and then returns nil.

But, in reality xlib:event-listen treats timeout = 0 the same as timeout = nil This is unfortunate because it implies that checking the event queue could require the client to block for at least 1 second. An extremely long time in today's desktop world. Ideally the function would be rewritten, so that timeout was made nil by default, and explicitly passing the argument of timeout = 0 when calling the function would ensure that the function wouldn't block even if there was nothing on the queue.

(defun event-listen (display &optional (timeout nil))

     ....

    )

with the behavior of

=> (xlib:event-listen *display* 0)
nil

Given the extreme conservatism of CLX, and the fact that this behavior seems to have been in place for a long time, perhaps the better alternative would be to change the documentation to correspond to current behavior: timeout 0 is treated the same as nil, and that if a no 'blocking' operation is wanted the user should instead specify a very small rational or real number, e.g. (xlib:event-listen *display* 0.001)

dkochmanski commented 6 years ago

There must be some problem in your code, because passing timeout=0 does as expected return immedietely regardless of the queue state. For instance:

sbcl

CL-USER> (defparameter *display* (xlib:open-default-display))
*DISPLAY*
CL-USER> (xlib:event-listen *display* 0)
NIL
:TIMEOUT

ccl

CL-USER> (defparameter *display* (xlib:open-default-display))
*DISPLAY*
CL-USER> (xlib:event-listen *display* 0)
NIL
:TIMEOUT

This mechanism may be broken for some implementations, but in such case it should be considered being a bug (and PRs are welcome).