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

From: Kevin Tew (tewk at cs.utah.edu)
Date: Wed Nov 7 12:16:20 EST 2012

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121107/03e216be/attachment.html>

Posted on the users mailing list.