> Hm. Are you forgetting that "objects" in Python are all by reference. > And therefore it is pretty much impossible to "contain" them. > > Imagine I create a message: > > msg = [ [1,2], [3,4] ] # Notice msg is a reference to a tree of 7 objects >
That's a good point, and one I hadn't really thought of. Erlang gets around this issue by doing a "deep copy" and can at times pay a penalty for it. I see three other options how this may work: 1) make all mutable types objects. This way lists would look like objects, and therefore would get their own tasklet and message loop. This would be very inefficient. 2) make lists a special type that is implemented internally with a highly efficient locking mechanism. 3) make lists single threaded, and when passed outside of the owning thread( eg. foo(self.barlist) ) convert them into #1 on the fly. I understand that I'm suggesting something a bit deeper than "a simple hack". And I know this would break allot of code, but I'm hoping that with some modifications, a framework could be developed that would be as good (if not better) than Erlang in terms of performance, while keeping the extremely elegant OOP-ness of Python. As some background to this project, I just got done studying Erlang for a couple months, and while I love allot of the concepts of the language, such as cheap threads, and message passing, I hate the syntax and the fact that there isn't a good way to move data around in the program. I think we should look at this as a higher approximation of the real world than what we are used to with OOP. Right now, I am typing at my computer, as I press a key, I'm passing a message to the machine. It responds by passing information back trough the display. At no time do I open it up and read the data as it is being calculated. The entire world is based off of this concept of passing "messages" in between objects. Not in-between functions as in Erlang, or sharing memory as in current Python implementations, but passing messages in between objects. If we can get a framework to match this model, I think it could be quite usable. I'm going to develop the stackless version of this, and try to migrate it to a VM-per-CPU model. At that point I'll see what the performance hit is, and how well it performs against Erlang. Keep the questions coming I'm very interested in getting feedback. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
