freenode/#clim - IRC Chatlog
Search
17:59:43
jackdaniel
http://hellsgate.pl/files/f92d1dbc – finished, now we can put border over rows, columns or cells and expect compeling effect
18:02:30
nyef``
On my side, I've got a theory for how and where the CPU reference I've been working with is wrong (both in "simple" errata, and in how it presents certain aspects of the instruction set), and I've been working out threading implications for NQ-CLIM.
18:04:13
jackdaniel
do you mind sharing them or you want to work on them a bit more before presenting results?
18:04:57
nyef``
Two important scenarios that I considered are doing I/O multiplexing in an application thread in both threaded and non-threaded NQ-CLIM implementations, and what happens when writing an application with a pane that behaves as a frame manager that accepts frames running on other threads.
18:06:51
nyef``
The frame manager thing is... well, I'm not quite sure how to express when that comes into play, because it's a somewhat unusual set of circumstances.
18:07:19
nyef``
Basically, if I have an application, and I want one of the panes to run on a separate thread.
18:08:09
nyef``
That pane has to have a separate event-queue (because event queues are single-reader, multiple-writer). But it has to handle repaint and whatnot "sanely".
18:09:29
nyef``
In some situations, making it a mirrored sheet breaks enough dependencies that a lot of stuff Just Works.
18:11:53
nyef``
Anyway, I still haven't fully nailed down the event queue discipline in NQ-CLIM, but I know that they're going to be single-reader, multiple-writer.
18:12:09
nyef``
And that means that I can plausibly get away with a largely-lockless implementation.
18:12:50
nyef``
But back to the thing with parent and child sheets having separate event queues, and thus "belonging to" separate threads.
18:13:28
nyef``
As I said, having the child be a mirrored sheet breaks a lot of dependencies because it pushes them to the port level, and beyond that to the host windowing system.
18:14:02
nyef``
But on a port where the host only provides one level of windowing, or on a purely framebuffer port, that doesn't work.
18:15:59
nyef``
As far as drawing goes, though, having the medium lock the "output surface" and re-checking its effective transformations and regions before every drawing operation is sufficient to prevent problems with corrupted output due to whatever, especially if sheet geometry and hierarchy changes also take the output surface lock.
18:16:54
nyef``
Doesn't have to be part of the mirror, either, the lock can be on the mirrored-sheet-mixin.
18:17:52
nyef``
This, of course, slows down drawing operations. But then I found that you can tell a medium to BUFFER the drawing operations and then play them out all at once, meaning that it only has to take the lock once.
18:19:07
nyef``
This turns out to be described in CLIM II 15.6, which is nowhere near the rest of the description of MEDIUMs, and WITH-OUTPUT-BUFFERED is badly specified as well.
18:21:10
jackdaniel
so basically if you have 15 gadgets in one pane, you will have 16 threads, do I understand correctly?
18:21:38
nyef``
No. There's absolutely no requirement that a mirrored sheet have a separate thread. Or a gadget, or anything like that.
18:23:24
nyef``
There should be basically no reason, in normal operation, for a single thread to monitor multiple event queues.
18:24:19
nyef``
And there should be no reason for an event queue to be monitored by multiple threads, even in *abnormal* operation.
18:25:11
nyef``
This is for cases where you want some part of an application to be "run by" another thread. Or, as I said, when implementing a frame-manager more generally.
18:27:52
nyef``
Let's have a hypothetical situation: I'm writing a Visual Studio type IDE, and I want to have a "compilation" window that pops up occasionally.
18:28:27
nyef``
For various reasons, I don't want to have to deal with that window in my main UI thread, it needs to be in some other thread, but it also needs to appear as part of my frame layout.
18:30:34
nyef``
It gets its own output-history, because it's an output stream. It gets its own event-queue, because it's running on its own thread. And dragging it around, making it visible or invisible, directing it to repaint when necessary, are all things that happen on my main UI thread.
18:31:12
nyef``
But its actual *repaint*, output processing, and so on, all happen on *its* thread, not my main UI thread.
18:31:36
nyef``
If it has buttons for whatever reasons, they are handled on *its* thread, not the main UI thread.
18:32:20
nyef``
But if I'm dragging it about while it's trying to draw more output, things must not break.
18:33:44
nyef``
If I'm in a LispOS scenario, there's only one mirrored sheet, and it's the graft, and the frame manager (window manager) is a CLIM application, then things need to work, and they need to work by design.
18:37:10
nyef``
There's also an interesting implication that I came across for host windowing environments that consider event delivery for mirrors to be affine to the thread that creates the mirror. I'm going to have to update issue #170 with that one.
18:41:37
nyef``
Mmm. You could probably do a WinAPI port that way as well, marshalling all CreateWindow() operations for REALIZE-MIRROR over to the port event thread.