From tismer at stackless.com Sat Apr 3 02:00:06 2004 From: tismer at stackless.com (Christian Tismer) Date: Sat, 03 Apr 2004 02:00:06 +0200 Subject: [Stackless-dev] New stable version Message-ID: <406DFE86.4090605@stackless.com> Dear friends, there were a few bugfixes in - nonrecursive kill (bad condition killing current, thanks CCP) - more fixes for power pc configuration (thanks Bob Ippolito) - avoiding warnings (thanks Stefan Drees) A major change was the introduction of a special implicit function parameter, to get rid of duplicated code for non-recursive versions of internal functions. By this, type objects are now again absolutely identical to Standard Python's, and so it should be. Execfile and eval are stackless. Generators can be pickled when being run. This is now considered the current stable release. The latest CCP bugfix concerning tasklet.become() wiull now be reverted in the dev trunk, and the frame f_execute protocoll will be changed to take an explicit retval parameter. Then I will also implement continuations, in a very limited, careful way, on a user request. There will be nothing but callcc. -- Christian Tismer :^) Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ Stackless-dev mailing list Stackless-dev at stackless.com http://www.stackless.com/mailman/listinfo/stackless-dev From tismer at stackless.com Tue Apr 20 03:06:29 2004 From: tismer at stackless.com (Christian Tismer) Date: Tue, 20 Apr 2004 03:06:29 +0200 Subject: [Stackless-dev] Lots of changes - need more unittests Message-ID: <40847795.4090303@stackless.com> Dear developers, as you might have noticed, I have done a lot of changes in the dev branch. The soft-switch protocol has changed a lot, in order to be cleaner and to support a move towards thunks and greenlets. This was quite a bulk of work, and there is still a lot of things to do. The pickling has become more compatible, since I don't rename types, any longer. Instead, they all end up in the builtins. I'm not sure if this was a good decision, but finally, it is somehow logical. I tried to circumvent this by involving copy_reg, but it didn't help much. I'm still patching the types to support pickling. I don't think this is too bad. One bad spot is the existance of the modict. I think to remove it, tomorrow. Another thing is cPickle. I added a way to overcome its recursive behavior, by simply using hard-switching. I think this kind of treatment is what it deserves. Fortunately, unpickling *is* non-recursive, already. I recognized that late, after I had supplied a patch, already. :-) Well, shit happens. Since I have unlimited pickling, now, I could drop all the changes to tracebacks and implement their pickling using simple recursion. I will probably simplify tasklet pickling the same way, soon, but this is less urgent, since tasklets are my own. I was very happy to see a new unittest from Stefan Drees, and I'd really appreciate to see some more, very soon. There is also some lack in testing the Stackless API, which is meant to be used by extension writers. A special area is the case where Stackless internals are called without initializing Stackless. This should always work, but I need some decent tests for this. Maybe someone would like to provide a module for this? cheers -- chris -- Christian Tismer :^) Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ Stackless-dev mailing list Stackless-dev at stackless.com http://www.stackless.com/mailman/listinfo/stackless-dev From tismer at stackless.com Fri Apr 23 02:41:32 2004 From: tismer at stackless.com (Christian Tismer) Date: Fri, 23 Apr 2004 02:41:32 +0200 Subject: [Stackless-dev] The New Pickling Concept Message-ID: <4088663C.2080401@stackless.com> Stackless pickling has got a complete re-write. There is not any single type patched any longer. Instead, all types have got a shadow type which is living in the stackless._wrap module. The wrapper types create a subtype of the real type when invoked. On __setstate__, they set the real data (to avoid deep recursion), and they set the real type. Afterwards, just an innocent object of the target type exists, which is not changed at all. This is just an intermediate step towards the final solution. I will now rewrite things, again, in a much more generic style. Types-to-be-pickled will just have to provide a __reduce__ function and a __new__ function. The framework will make sure that the __new__ actually takes place in the __setstate__ phase. With that concept, we will have no problems with recursive objects. I think this is worth a lightning talk at Europython. ciao - chris -- Christian Tismer :^) Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ Stackless-dev mailing list Stackless-dev at stackless.com http://www.stackless.com/mailman/listinfo/stackless-dev From tismer at stackless.com Wed Apr 14 20:41:16 2004 From: tismer at stackless.com (Christian Tismer) Date: Wed, 14 Apr 2004 20:41:16 +0200 Subject: [Stackless-dev] Re: Stackless and the future In-Reply-To: <6BFF12C3797859459199582737A50A770F30B5@postur.ccp.cc> References: <6BFF12C3797859459199582737A50A770F30B5@postur.ccp.cc> Message-ID: <407D85CC.90306@stackless.com> Kristj?n V. J?nsson wrote: > Yesterday, I was having fun implementing the pthreads synchronization > primitives for stackless. I was doing this using channels, waking up > sleepers with a send(None). Then I realised that channels have a > problem: They cause targeted scheduling. Yes. This is what CCP loved the most, because it made mouse handlers very reactive. But one size doesn't fit all :-) > When I send on a channel, the context will be switched immediately (or > after blocking) to a receiver. This means that if I implement a mutex > using a channel, and do a send() when unlocking, control will > immediately be given to the waiting tasklet. This might be a deficiency, but I think it is quite easy to get along with: If your mutex code does a schedule(), right after being unlocked, it will become the last runnable in the queue. > And so, nothing will > happen in the system until all tasklets waiting for this mutex have > finished. Currently I fix it using a delayed send by creating a tasklet > for this purpose and waiting for it to be scheduled in its own good > time. But it got me thinking that maybe channels shouldn?t be the basic > synchronization mechanism in stackless. Maybe this is what you have > been talking about lately, with greenlets, and all that. But here?s my > suggestion. Channels by themselves are a fine thing, since they do real blocking. What it bad is probably the default decision what they should do when data is available. This is all going to be virtualized and definable. > Basically I think that the most primitive syncrhonization primitives > should be to allow one to make a tasklet runnable or not. I know that > this is now implemented by chaining them either in the run queue or on > channels. maybe this could change. But a tasklet could go to sleep with > something like > stackless.getcurrent().runnable(False) > stackless.yield() > > A tasklet could be made runnable again by another tasklet, thus placing > it in the runnable queue. Discussions on the sprint have gone into the opposite direction: There should be no runnables queue at all, which makes the greenlets. > yield() could take as an argument a runnable tasklet if we want to > explicitly yield to that one at this point. This could be used to > implement channels in their current form, or to implement a custom > scheduler. > > channels could be implemented with a regular python list, and the > runnable() tasklet method and the yield() method. > > Basically, I think that the channels carry to much scheduling semantics > along with them to work as the primary synchronization object in > stackless. (I did write a DelayedChannel(stackless.channel) that > delegates each send() to a worker tasklet, but it does seem a bit over > the top. I do agree that there are too many decisions "under the hood". But I don't know exactly which direction to go, so I cc'ed the stackless list for discussion. cheers - chris -- Christian Tismer :^) Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ Stackless-dev mailing list Stackless-dev at stackless.com http://www.stackless.com/mailman/listinfo/stackless-dev