I’m thinking about using OpenGL in more than one window, so I would like
to get into multi-threading. Since only one window can be active at
any time, and since I call glMakeCurrent at the start of my rendering
loop, I don’t see any obvious conflicts with multi-threading.
Does GL and multi-threading work well with this kind of setup?
The windows have their own rendering contexts, nothing is shared.
Is there a maximum limit to how many rendering contexts I can create?
IF so, how would I query/find out this limit?
Are you using Windows OS? If so, check out msdn.microsft.com . It has just about everything you might want to know about coding in Windows. If not using Windows, I have no clue, but you may wish to make another post telling people what you are using.
I believe that threads are considered by the operating system (any OS) to be separate programs so it is probably more memory dependent, though too many threads will probably cause greater contention for same resources and/or add some overhead as the system switches from thread to thread. Typically, 1 thread per processor is acceptable but probably 2 or 3 can still remain somewhat efficient. But, a UNIX box like SUN deals with threads much more safely and efficiently than a Wintel machine.
Anyway, you need to weigh the benefits of multi-threaded vs the slight (or great) decrease in processing power.
As far as I know there is no limit to the number of threads aside from practicality.
Why do you assume that you need one thread per window?
Why would you want even one thread unless the program is intended to run on a multiple cpu box?
What kind of thread, worker or UI are you considering and what exactly do you want this thread to do for you?
Yes, I’m using MS Windows, I mentioned MFC in the topic, so I assumed everyone
would understand, unless people can actually use MFC on other OSes. 
And I’m creating UI threads. Now, that I think about it, I don’t think
I will ever want to open 100 windows at a time, so I’m not going to
impose any limits on my program.