From dmarks@dionysus.phs.uiuc.edu Thu Feb 19 16:05:32 1998 Return-Path: Message-ID: <19980219180206.10838@dionysus.phs.uiuc.edu> Date: Thu, 19 Feb 1998 18:02:06 -0600 From: Dan Marks To: David Jeske Subject: Re: Optical Table is cool! Reply-To: dmarks@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e Status: RO Content-Length: 2492 Lines: 106 On Wed, Feb 18, 1998 at 11:01:23PM -0800, David Jeske wrote: Here is something sort I wrote on contexts: Contexts Dave, here are some of my ideas regarding contexts. (sorry for the brevity but i am writing this on my Pilot) The idea of a context is to have a chain of subroutine execution share a group of variables. A block of code can be declared to be inside a context. A context is declared like a structure or even better, a class. A context has instance variables and possibly methods that operate on the context's instance variables: context myContext { MyClassPtr myCP; OtherClassPtr ocp; myContext(myContextPtr oldContext, data newData); // instantiator - you call this // to create a new context, // using elements of an old context ~myContext() // destructor - takes care of // stuff before the context is freed lock() // locks a context in a thread // - takes care of locking any objects // inside the context that may be // used outside the context. unlock() // unlocks a context in a thread // - unlocks the objects inside the // context } To declare a specific context use: myContextPtr contInst; This declaration of contInst is actually only a POINTER to the context. The actual instance would be declared as needed with the new constructor in the global heap. The pointer points to the currently referenced context and the pointer is stored inside the Thread Local Storage, so each thread can be in a different context. Then a class can use the context by accessing the variable contInst, so the code uses contInst in the code. To declare a new context one can use a context instanstiator: use (contInst=new myContext(contInst, data); free(contInst)) { statement using contInst } This is just syntactic sugar for the following ( myContextPtr saveContext; // local variable on stack; saveContext = contInst; contInst = new new myContext(contInst, newData) statements using context free(contInst); contInst = saveContext ) it is not necessary to create a context inside the block. Important: contInst is kept per thread so when a new thread is created a new copy is for each thread (Thread Local Storage) Cool things are possible: synchronizing threads on context so that two contexts don't run simultaneously Dan From jeske@... Thu Feb 19 16:30:02 1998 Return-Path: Message-ID: <19980219162948.09466@home.chat.net> Date: Thu, 19 Feb 1998 16:29:48 -0800 From: David Jeske To: dmarks@..., jeske@..., bleisch@... Cc: steve@inquisit.com Subject: Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.2 Status: RO Content-Length: 2882 Lines: 61 Hey Dan (and others along for the ride), Dan and I got in this conversation about "variable context" and how they might be formalized into a language construct. This is my thinking along those lines. What is a context, and where does the need to use one arise? Lets walk back to the days of non-object programming systems. A body of C code. The local variables are convinently held on the stack. Global variables hold system wide state for that subystem. For example, in Lua, all the data associated with your lua program is held in global variables. (or at least there are global variable pointers) Now, people have decided that they want to use multiple lua interpreters. So they took all the Lua state and put it into a structure, and they have a global pointer to that structure. To change interpreters, you just change where that global pointer points. Yet some want to run multiple interpreters at once, so yet another code change is required where we explicitly pass in a pointer to this global lua State so there can be multiple versions around. Objects in class based systems present one example for solving this problem by allowing variables to be bound to one of three places instead of one of two. There were always "globals", there were always "locals", and objects in class based systems also allow you to add state to the "object instantiation" itself. I propose that the idea of "contexts" should be a general concept which handles all of the above issues, but instead of there being an arbitrarily decided number of contexts associated with the language, the programmer will choose how many contexts he needs. This idea seems very similar to what I've seen in "Self" with how they separate object data not only from object code, but also from other non-similar object data. It also is going to give us a cleaner place to put data in interface based systems like COM. Afterall, sometimes it won't make sense to have state shared for all the interfaces and object provides. -- Here is an example of how contexts might be put on top of C. Any "source file" would automatically have its own context, and a class would have its own context. The class context would also have pointers to any "global source file" contexts which it used. Static class variables would also be put into a separate context. So in an instantiation of a class you have: obj ptr -> ptr to instance data -> ptr to vtable -> ptr to static class vars -> ptr to global context1 -> So if you wanted to, for example, have two sets of "static class vars" you would just change the pointer to that context for a given object instantiation. We would really like to do away with this concept of globals though. Instead, all contexts should be declared, even if they are shared. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@...