[racket] XNextEvent blocking 'read' in other thread?

From: Kevin Tew (tewk at cs.utah.edu)
Date: Thu Nov 8 12:34:39 EST 2012

XPending returns an integer and I was using it in a boolean context 
which led to unintended blocking. Fix coming.

On 11/07/2012 12:27 PM, Laurent wrote:
> Thank you all very much for your answers, they are very helpful.
>
> AFAICT, after some light testing, Jon's code does what I want, but 
> Kevin's one is still blocking.
> Also, both versions seem to suffer a heavy cost of a few seconds of 
> initialization compared to the basic XNextEvent version.
>
> Laurent
>
>
> On Wed, Nov 7, 2012 at 7:24 PM, Jon Rafkind <rafkind at cs.utah.edu 
> <mailto:rafkind at cs.utah.edu>> wrote:
>
>     Here is some goofy code from my barely-started window manager
>
>      (define (run)
>         (define (make-root-node)
>           (send (new RootNode (window x-root))
>                 add-windows
>                 (get-all-windows)))
>         (printf "Welcome to smokey\n")
>         (XSetInputFocus x-display None 0 0)
>         (let ((events (make-channel)))
>           ;; (run-events-thread events)
>           (start-x11-event-thread x-display events)
>           (let server-loop ((root (make-root-node)))
>             (sync (handle-evt events (lambda (event)
>                                        ;; (printf "Event ~a\n" event)
>                                        (server-loop
>                                          (send root handle-event
>     event))))))))
>
>
>     On 11/07/2012 11:13 AM, Kevin Tew wrote:
>>     yeah I'm putting it in a subdirectory.
>>
>>     I'm also trying to get XConnectionNumber to work first.
>>
>>     Kevin
>>
>>     On 11/07/2012 11:09 AM, Jon Rafkind wrote:
>>>     xlambda :p
>>>
>>>     would you like to commit it to the repo?
>>>
>>>     On 11/07/2012 10:23 AM, Kevin Tew wrote:
>>>>     I've attached my in-progress port of xmonad to x11-racket.
>>>>
>>>>     Kevin
>>>>
>>>>     On 11/07/2012 10:16 AM, Kevin Tew wrote:
>>>>>     Racket threads are green or user threads, they are not
>>>>>     scheduled by the operating system.
>>>>>     Blocking on a socket in XNextEvent blocks the entire Racket VM.
>>>>>
>>>>>
>>>>>     You need to use XConnectionNumber to get the X socket file
>>>>>     descriptor number and then create a port that you can sync on
>>>>>     with Racket's sync functionality.
>>>>>
>>>>>     I'm not sure how you would create the port using the ffi.
>>>>>
>>>>>     See
>>>>>     http://fixunix.com/xwindows/91558-xconnectionnumber-select.html.
>>>>>
>>>>>     Kevin
>>>>>
>>>>>     On 11/07/2012 09:58 AM, Laurent wrote:
>>>>>>     Hi,
>>>>>>
>>>>>>     I don't know if this issue is due to me, Racket, Xlib FFI or
>>>>>>     Xlib in itself, but I'm struggling with it. Hopefully someone
>>>>>>     knows.
>>>>>>
>>>>>>     In a multi-threaded application using Jon's Xlib FFI (
>>>>>>     https://github.com/kazzmir/x11-racket ), I'm using one thread
>>>>>>     for processing X events with XNextEvent, which is a blocking
>>>>>>     call (apparently on a socket).
>>>>>>     I have another thread that listens to a tcp port, and does
>>>>>>     not need to do any X call.
>>>>>>
>>>>>>     The problem is that the second thread blocks on 'read' even
>>>>>>     if there is something in the queue to read, unless some X
>>>>>>     event unblocks XNextEvent, in which case both threads run,
>>>>>>     until there is no X event left (and XNextEvent blocks again).
>>>>>>
>>>>>>     I have called XInitThreads prior to any other X call to
>>>>>>     enable threads (and the return values says it's ok).
>>>>>>
>>>>>>     Any idea anyone?
>>>>>>
>>>>>>     Thanks,
>>>>>>     Laurent
>>>>>>
>>>>>>
>>>>>>
>>>>>>     ____________________
>>>>>>        Racket Users list:
>>>>>>        http://lists.racket-lang.org/users
>>>>>
>>>>>
>>>>>
>>>>>     ____________________
>>>>>        Racket Users list:
>>>>>        http://lists.racket-lang.org/users
>>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121108/706c55eb/attachment.html>

Posted on the users mailing list.