On Mon, Sep 6, 2010 at 3:06 AM, Gabriel Lavoie <[email protected]> wrote: > how to manage this problem with Stackless. On my side, it doesn't help that > much because I have to work with many tasklets executed on different > interpreters but still exchanging data through channels. The idea of my
Your use case is of course a good example of where Stackless would never have provided the ability to do this. This would always belong in the meta-framework you wrap around Stackless to get the distribution. It, to me, highlights that keeping Stackless as a generic base set of functionality, was the right choice. > Master Degree project is to make Stackless Python distributed with easy > tasklet migration between interpreters. It's not perfect but right now I > have hybrid channels that can exchange data between local or remote > tasklets. I made some kind of distributed objets using PyPy proxy object That's the easy part :-) > space for objets that shouldn't be copied when they are sent to a remote > tasklet (like big objects). I also tried to manage the best I could the case > of global memory and shared object. This could still be improved. That's the hard part. > The idea of creating a parent/child relation between tasklets is manage the > case when two tasklets in relation are not executed on the same interpreter. > If the remote tasklet dies or the interpreter where it was executed dies, > the parent tasklet should be notified in some way. Trying to manage this > with a weakref would be a nightmare for the programmer if the remote tasklet > moves a lot between interpreters. I want this to be managed by my library. The more and more I read this, the more it sounds like your framework needs to be managing it. > Also trying to wrap the function used to create a tasklet isn't really > useful when the interpreter running it dies and the parent is elsewhere. In > any case, the way you described to do it is still some useful material for > my thesis. ;) I look forward to when you finish it and send a link to this mailing list :-) Richard. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
