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
