threads vs. greenlets (was Re: New stackless proposal)

Christian Tismer wrote:

> This is a vague definition.
> I'm seriously asking what "running" should mean.
> If something i waiting for an event, for instance,
> it is suspended, not terminating. Is it running, then?

Yes, a suspended thread would have running?() == True.

Having a suspended?() question wouldn't make much sense since it could
change so fast.

> ["you are more into threads than I am"]
>
>> A thread is just a function that runs.  What could be simpler than
>> that?   I think you are maybe assuming things about my threads that
>> aren't there.
>
> Maybe. It is probably the thread buzzword.

I hope so.

>> When you pointed me to greenlets before all I saw was
>> implementation-specific stuff for the Python stack.  I don't know
>> how to translate that.
>
> That was just a detail, not what I meant.
> The Greenlets are somewhat a minimum implementation
> of something switchable. There is no concept of
> a thread, no pausing, no timeout, no priority,
> no nothing. There is just a function to jump
> off from one Greenlet and to continue with another
> one. Every other concept can be put on top of that.
> I'm trying to understand whether this is what you
> are after, or if it is more.

I want the base concept of the greenlet available for the programmer to use.
I don't want any other feature I add to harm that base greenlet concept.

I also want to add other concepts to make the Thread be able to do
everything the OSThread can do.  So far I think the OSThread concepts do not
harm the functionality of the base greenlet.  If I am wrong then I will
remove the OSThread concepts.

See my later response about this.

>>> Why should yield() be any different from yield(value) ?
>>
>> So your channel.transfer() works without a value also?  If so then
>> I'll make yield() work just like yield(value).  I thought a value
>> was always needed.
>
> For historical reasons, send passes a value and receive
> returns a value. Internally, they do an exchange.
> There is no reason not to echange two values, or
> not to just do noting.
> It is convenient to do a data echange, but it could
> even be emulated. What is really needed is the
> control flow.

What if we say that they always exchange a value but it can default to None.
This would be just like a function.  Then yield() would be different than
yield(value)

> Sure I can, it is not unsafe.
> my kill exception is an ordinary Python exception that
> is a subclass of SystemExit, namely TaskletExit.
> Protected code is in try..finally blocks, and code
> can always capture any exception.
> The only unsafetyness is that my code might run
> forever if it ignores exception. :-)

I understand now.  You are correct.

>> Also I really don't understand this simpler model.  Can you please
>> try to explain what can be simpler?
>
> Wel, I agree that you will want these functions most probably,
> they just have the drawback that they force you into
> decisions, early. If your thread can sleep, then
> you need to decide whom to run, instead, who wakes it
> up again, and so on.
> By simple model I mean something that doesn't need this,
> it is all up to the user. That's the basic part.
> Everything that has to do with process control is
> on a different layer.

I understand what you are saying now.  You want only co-routines on the
Thread layer and functions like Sleep on the OSThread layer, correct?

Do you included pre-emption as something that should be only on the OSThread
layer?

Now that I really understand what you are asking for I will give it some
thought.

Sleep could be avoided by the programmer just by not using it.  We could
maybe make pre-emption a tuning parameter.  It could be turned on or off and
the granularity could be fine-tuned.

I'm going to stop this response here because we really have two different
discussions going on.  One is threads vs. greenlets and the other is
implementation.