freenode/#clim - IRC Chatlog
Search
4:06:06
beach
Hello slyrus. Since you often ask for SICL updates, I managed to connect the HIR interpreter to a primitive version of Clordane: metamodular.com/clordane.mp4 Only some simple stepping works for now.
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.