JB> 1.  I'm thinking that the main thread should create child windows
 JB> and manage them and their messages, creating threads as necessary
 JB> for display, calculation, etc.  Or should each editor window have
 JB> its own message queue (and therefore, thread)?  Is it better to
 JB> have numerous threads running (albeit, blocked and waiting on
 JB> messages) or to create and terminate them as necessary?

It is not necessary to ever have more than one thread that creates windows;
 I find this model desirable.

Whether a thread is created ahead of time,  or on demand,  depends on what
you are doing with it.  I rarely start on-demand threads.

For your program (guessing at requirements),  I would probably start a
worker thread for each opened file (assuming each opened file also has a
window).  The worker thread would be general purpose,  and handle one
message at a time.

 JB> 2.  Is it kosher to use the same function as the entry point in
 JB> a thread, even if that function is currently running another
 JB> thread?

Definitely.  The same goes for window procedures.

 This goes primarily w/ the 'numerous, always running
 JB> threads' question above.  Each 'file open/new' request would
 JB> create a thread using the same function as the entry point, and
 JB> this may have consequences toward values in variables.  It's this

The code you don't have to worry about;  the data you do.  Since each
thread has its own stack, any automatic (local, stack) variables are
automatically unique.  Global and static variables are shared,  and must be
avoided or protected with semaphores.

 JB> concern that leads me to believe that each window should run
 JB> under the main thread.

Even still,  each window must know who its thread is,  so each window will
need to keep some private instance data (See WinSetWindowPtr()).



--- Maximus/2 3.00