freenode/#clim - IRC Chatlog
Search
4:09:33
loke
What is the “correct” way to send asynchronous messages to a CLIM thread? (I.e. I have a UI that needs to be updated in real-time based on some external event in a different thread)
7:25:44
jackdaniel
loke: there is no correct way at the moment, both event-queue and stream access are prone to races and/or corruption. you must do it from the same thread as the event loop
7:28:46
jackdaniel
I even have an idea how to mitigate the issue: in case of queue we need a mailbox which is thread safe (some implementations have it, but implementation is not super hard), in case of stream we need around methods which check for thread affinity (if foreign thread, then operation is enqueued)
7:30:57
jackdaniel
but prerequisite to meddle with multithreading is fixing single-threaded run (there is also ticket for that)
7:31:11
jackdaniel
before we make things more complicated we need to assure it works just fine for the simplest of cases
7:32:49
loke
I looked at some older code I wrote, and it seems as though it might be a correct way of doing it
7:34:00
loke
simply call EXECUTE-FRAME-COMMAND on the appropriate frame. There is code in there that, if the current frame is not the same frame, then it will create an event that will execute the command later. The event is then inserted in the event queue, and it does take a lock while doing so, which suggests to me that they thought about this.
7:36:41
jackdaniel
1) this is about commands; 2) event-queue-append is not thread safe, so this solution is erroneous; 3) in principle this is a solution which depends on the event queue being mailbox (as I suggested, though this assumption is not fulfilled)
7:38:17
jackdaniel
no, with with-lock-held it is not efficient, but correct, there is no need to worry
7:38:48
loke
Currently, my need for this has to do with the Maxima client being able to tell the documentation frame to display a specific page of documentation.
7:39:14
loke
But in the longer run, I want to use this mechanism to tell a frame that the “global input context” has changed.
7:44:24
loke
jackdaniel: The bug in question mentions that genera had a concept called the “active application”
7:45:02
jackdaniel
maybe clicking window decoraction (like you have active window with keyboard input)
7:46:32
jackdaniel
why wouldn't it? also: what is the alternative approach? (please add it to the ticket)
7:47:19
jackdaniel
I find it very sane: only active frame is active for input (even if input comes from other frames), that has a direct analogy to how keyboard input works, even if it is a virtual keyboard
7:49:08
loke
Let's say you have windows A and B. I'm working in window A and it's waiting for a presentation of type X. I now click on such presentation in windows B. However, before the mouseclick is delivered to window B, the window manager has already selected window B, meaning that B will not know that application A was “active” before the click.
7:49:48
loke
And it depends on which window manager one uses, if the window is selected before events are delivered to it. If you configure “click to select”, then you can't click in an unselected window.
7:51:38
jackdaniel
we may maintain "activity" status on our own then. all frames must be in the same process anyway (for presentation-aware input). do you happen to have an alternative solution proposal?
7:52:34
loke
Well, the only one has been to consider a “global input context” that would be consulted along with the lcoal one. However, you raised some good points about that idea yesterday.
7:52:50
jackdaniel
last thing (half-jokingly): we may come up with our own window manager, we have blackbox and such ;-)