onsdagen den 10 augusti 2005 22.47 skrev Armin Rigo: > * threading: implementing this requires a mixture of source-code-level > changes and help from the translation process, depending on the > approach taken. At the moment we have no threads at all. There are > two threading models that are relatively easy to implement by now, and > more to think about: ... > 3) there are also other less well-thought ideas for threading, mostly > along the lines of per-object locking. Here too, it should be > possible to get a not-too-bad result without having to insert locks > everywhere by hand. For example, we could reuse the proxy object > space mechanism for a LockingObjSpace which first acquires the lock > of each object involved in each space operation. > > * finally, let's consider the translation process itself. It is > flexible in principle, but it's not really designed as a framework > with a well-defined API or hooks to plug into. However, it is > possible to hack here and there to change various translation aspects. > This is, to some extent, the whole idea of PyPy's flexibility: a > framework with hooks and APIs allows only so much experimentation; > sooner or later the ability to directly code things differently is > more powerful. Nevertheless I guess that some refactoring would help > to make localized translation aspects easier to change, e.g. by providing > more "policy" objects to control the process, or (for OOP enthusiasts) > by designing the classes with subclassing in mind.
A loose idea that I have had would be to have one object space per thread. There would be several different possibilities for how to access an object that isn't in your own object space; one would be that the creating thread would continue to own the object. Another one would be to marshal the object and transfer it. A third one would be to transfer shared object to a shared object space. Jacob _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
