freenode/#clim - IRC Chatlog
Search
6:43:32
loke
jackdaniel: about the delayed events when executing a comman asynchronously... Can you remind me, was the reason for this that the main event thread is blocked in XNextEvent()
6:46:58
loke
Oh wait... Sorry. The event processing thread and the application-frame's thread are different.
6:48:02
jackdaniel
I still don't recall any function in clx called XNextEvent(), but you are correct, by default port has its own thread which fills the thread-safe fifo queue with events
6:53:35
loke
In StumpWM, I had the need to get PROCESS-EVENT to break out early, and the only way I could think of was to have CLX listen to an extra file handle (a pipe), and then write a byte to that pipe in order to get it stop blocking.
6:56:20
jackdaniel
I think that the correct way to handle problem of multiple input sources is a thread-safe fifo queue
6:58:43
jackdaniel
CLX is responsible for handling communication with X server, not for managing multiple input sources
7:01:01
loke
I Xlib thread-safe? I.e. can I call drawing functions from two threads at the same time?
7:03:52
loke
If it isn't, wouldn't that be a problem since McCLIM does call xlib function from the application frame's thread (of which there may be several)
7:05:37
jackdaniel
I think that until you keep your drawables separate you are fine, but once again - I don't know, please check clx documentation or code for hints. such guesswork on my side may only confuse you
7:26:44
PuercoPope
loke xlib, as in the C library is not thread safe, that is one of the motivations for xcb. Because clx predates xcb it likely isnt thread safe.
7:31:51
jackdaniel
clx has many locks and atomic operation definitions, so I wouldn't be very sure without verifying that first
7:33:24
jackdaniel
it is not uncommon for lisp software predating unix software to have superior features (at expense of i.e hardware requirements)
7:37:31
loke
I took a look at DRAW-LINE. it does do unlocked accesses (read/write) to member of the DISPLAY struct for example.
7:38:18
loke
The code that requests a new request ID is also not sycnhronised, to it's theoretically possible that two parallel requetsts get the same ID
7:41:51
jackdaniel
such code is usually executed inside with-gcontext which in turn may do some magic with bodies, that's why I've suggested further inspection
7:43:09
jackdaniel
either way before doing some changes to mcclim or clx because "clx is not thread safe" I'd first like to see a test case which proves that something is corrupted
7:44:57
PuercoPope
jackdaniel the problem was at the protocol level if iirc. Given that clx doesnt use cookies to identify requests I would be very surprised if they fixed the issue of thread safety of the x11 protocol.
7:46:00
jackdaniel
if I understand correctly you've suggested that xcb is thread-safe. but it speaks x11 protocol with arbitrary peers connected to the same server. I'm confused
7:46:20
jackdaniel
if x11 protocol can't be used in a thread-safe manner, then xcb could not achieve such feat
7:49:59
jackdaniel
so if <---> can't be implemented so asynchronous access works OK, then no x11 client could be thread-safe by definition
7:50:39
jackdaniel
and if x11 client sends something else than what x11 server expects, then you have garbage in, and depending on the server you have either garbage out or proper errors about invalid requests
7:51:32
jackdaniel
so xcb could only lift mitigations which were imposed by xlib architecture, but clx does not inherit architecture of xlib (despite the package name)
8:07:00
PuercoPope
I stand corrected, the problem was not at the protocol level but with the xlib implementation. rfc1013 mentions the unique ids per request.
9:02:37
loke
DISPLAY-BOFFSET is an accessor to the DISPLAY structure, and INDEX+ just adds index values.
14:02:59
scymtym
jackdaniel: i'm pretty sure i figured out the remaining issues with our event processing