[Stackless] Weakref support for tasklets

Christian Tismer tismer at stackless.com
Fri Jan 30 01:04:43 CET 2004

Bob Ippolito wrote:
> On Jan 29, 2004, at 4:52 PM, Christian Tismer wrote:

>> If it is doable from Python, then we don't need to
>> enforce it in the implementation. Well, I don't know.
> Remember, we are talking about [approximately] sizeof(PyObject*) bytes 
> per tasklet/channel here :)

That's right. But they accumulate, and I painfully added
GC support already, which is at least 2 words.
With every little piece of extra stuff we increase the size
of tasklets, and we increase initialization time.
Ok, ok, it is still linear :-)

Using derived types has always done a good job for me, when
trying to withstand wishes for new tasklet fields.
(Aka: you want a name field? Fine,d erive your own type
and don't bother me, since I'm anyway unable to fulfil anyone's
whish lists).
But anyway, I'm open for good reasons.

> I'm not entirely sure that a derived type is the best solution, because 
> it's entirely possible that the code that creates your tasklets is 
> logically separate from the code that needs to use them weakly (it is in 
> my case, at least).

Good point!

> Either way, unless you use __slots__ without a '__weakref__' then any 
> derived-from-python type is weakref-able, but adds more than the 
> sizeof(PyObject*) bytes per instance and means that there's more code 
> that the developer has to think about and write.  This is a reasonable 
> way to add weakref support to file objects (class weakfile(file): pass), 
> for example, but I personally think that they should be be weakref-able 
> by default (come on, a few bytes per open file?  You'd run out of 
> descriptors far before it matters).

Yes, you are absolutely right.
Also, until a few months ago, the associated C-stack objects of
the tasklet frames were so big that the tasklet size didn't count.
But now, 90 % of all tasklets seem to be soft-switching, which
brings size really really down, and tasklets count again.

For file objects, you are right, they are probably of equal size,
and they are limited by number.

If, on the other side, you have the customer who uses tasklets
to model his massive parallel algorithms, then size really does
matter (hear, hear :-) ), when it comes to the decision between
a taskjlet based implementation and one with those real cheapos,
called generators.
Do you see what I mean? Those are really cheap, and this is so since
they don't try to be everything, like tasklets tend to.

> Besides, weakref support is a good way to test tasklets and channels to 
> make sure they actually do get deallocated at the right time ;)  Adding 
> weakref support to channels is another 4 line change, and I have already 
> written simple unit tests to make sure that the weak references actually 
> work.  I'm going to go ahead and commit it.. if you strongly object, 
> then take it out ;)

Pff, ack, you knew in advance that I wouldn't :-)
Basically, I like the idea after thinking about it,
and until somebody tells me differently, I htink
the benefits are bigger than the drawbacks, right now.

thanks for opening these issues -- chris

Christian Tismer             :^)   <mailto:tismer at stackless.com>
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 mailing list
Stackless at stackless.com

More information about the Stackless mailing list