[Stackless] Problems with removing tasklet.

[Gustavo Niemeyer]

> > Where's the code? Where's the code? :-)
> 
> Ok -- before we get to that -- read Christian's response carefully... :-)

Don't worry.. I probably won't even use it. I'd just like to see what
kind of carefulness you took while writing it.

I'm sorry for being a little bit annoying, but I'd like to remove some
"clouds" I have right now, so that I can actually understand the current
issues, and perhaps contribute with some code or ideas.

Just so that you can feel a little bit confortable when detailing
problems, I've already ported the Stackless assembly code to a few
architectures, so I'm able to understand issues more deeply.

[...]
> In this case there are some hard to understand details: for starters
> (as Chris mentioned) not using any extension that might call back into
> the interpreter.

I'd like to get into those details. What's the real problem with letting
extensions call back the interpreter. Ok, because it could switch
context when that happens. The only case I could think so far is when
a variable allocated in the stack was returned, and while it was still
used, the context was switched. Is there anything else that we know
about right now?

> Also the way the exception handling works you should be careful to catch
> any exceptions *within* the tasklet -- and probably put the "main" tasklet
> away (remove it?) while you are free scheduling everyone else...
> 
> (Of course if you deeply understand what is really happening you can
> do the above...)

Exceptions are passed to the parent, aren't they? Is that the problem
you mention above?

> Oh ... I really don't know how much of stackless you understand -- Note:
> this is still not *real* pre-emptive scheduling --- anything you do
> that blocks the underlying OS native thread (i.e. blocking I/O) will
> block all tasklets running in that thread...

I understand. Tasklets are part of a single thread, and not seen by
the underlying kernel in any way.

> Also note that it is not really very "fair" scheduling either -- you
> can easily construct cases where tasklets are starved for cycles.  A
> fair scheduler is much more work...

Agreed.

Many thanks for your explanations and your code!

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]
_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless