[Openmcl-devel] thread overview

[Hamilton Link]

>> Is it the hemlock window thread, or does the main thread receive the
>> event and pass it to the
>> appropriate place?
>>
>
> Key-down events that're directed to hemlock windows get passed to
> that window's dedicated thread (the incoming NSEvent is mapped to
> a hemlock KEY-EVENT structure.)  Hemlock commands that affect the
> contents of the buffer and/or the selection currently do so by
> invoking methods on the main thread; I think that this is probably
> overkill.
>
> Other events (mouse-down/drag, etc.) related to hemlock windows get
> handled in the Cocoa event thread.

Redundant question... does this indirection create enough latency to 
limit the typing responsiveness and general redrawing speed of Hemlock 
editor windows?  I know the time is going somewhere, and this bounce 
seems it would be a likely candidate for investigation.  My impression 
is the state currently maintained by each window's native-thread-based 
process could be stored in some other way if someone took the time to 
work out what that data structure needed to be.  50wpm=300cpm=5cps so 
Hemlock should easily be able to keep astride of a 5Hz process 
(coding).

h