[Prev][Next][Index][Thread]

Re: FD 2.0 is quite a tool! --long post

On Fri, 16 Jun 2000 01:00:01 -0400 (EDT), "John Whittaker"
<johncwhi@earthlink.net> wrote:


> define variable display-thread-frame :: false-or( <thread-frame> ) = #f;

Dylan programmers would conventionally name this variable with '*'s :

  define variable *display-thread-frame* :: false-or( <thread-frame> ) = #f;

I'm also trying to encourage a convention where false-or types are made
explicit by combining the conventions for types and predicates as follows:

  define constant <thread-frame>? = false-or( <thread-frame> );
  define variable *display-thread-frame* :: <thread-frame>? = #f;

..

> 3.  The threads library is very rich.  It may have everything you'd ever
> need for threads and/or synchronization.  But, even though the code shown
> above works as two separate threads, I don't think it goes as far as I would
> like to in decoupling the two threads.

What did you think about the *hooks* or *observers* solution?  Chris also
pointed out the 'Channels' library which FD uses internally to decouple
components.

>  I'm not exactly sure what the
> sematics of call-in-frame is.  Do the calling thread and the called thread
> (i.e., the frame thread) synchronize in this function somehow?

Yes. I don't have Dylan's DUIM sources installed on my work machine following a
disk crash and a machine upgrade, but I think call-in-frame creates a
<function-event> which is pushed onto the event queue for the frame. The frame
thread then encounters this event just like the other 'real' windows ones.

>    Suppose I
> wanted the quicktune-thread to just dump its data, a buffer at a time, into
> a queue.  Then signal (I don't know how) the GUI thread that it has done so.
> How does a GUI thread running in a frame "catch" a signal?  I assume that
> the main thread loop for a gui frame looks something like:
> 
>    while ( alive )
>       event := get-next-event();
>       process-event( event );
>    end while;
> 
> The "event" would be some DUIM translation of Windows events (I'm guessing).
> Granted that this is all based on my possibly flawed assumptions, but how
> could you extend/modify the processing of a frame's thread to somehow check
> for a signal from another thread?

Your assumptions are roughly correct I think, and call-in-frame (or
apply-in-frame ) is already doing what you want. 

__Jason


_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp
References: