Re: New stackless proposal

Lenard Lindstrom wrote:
> On Thu, 8 Jul 2004 15:03:08 -0700 Mark Hahn <[email protected]> wrote:
>
>> http://prothon.org/wiki?pagename=StacklessLanguageFeatures
>>
> If a prothon thread must be declared using a "defInit" or "after"
> section of a function definition then there is no need for an
> "thread" keyword.

I removed the "thread" keyword from the proposal last night.  Good minds
think alike.

> Prothon thread declarations will likely outnumber
> OS thread declarations, especially when generators are prothon
> threads. So a "thread" statement that creates OS thread objects is
> not much of a convenience.
>
> The yield statement/function need not be a direct ThreadMgr method
> invocation. Simply define a built-in function as follows:
>
> def yield(value=None, to=otherThread):   # what is otherThread?
>     return curThreadMgr.yield(value, to)

That is how I expected it to be implemented in my proposal.  I should have
explained that.  Putting in otherThread was a mistake.  I should have said
None.  I will correct that.

> Having yield somehow know that it is on the right of an assignement is
> quirky given this feature shows up nowhere else in the language.

Yes, I pulled that last night also. I added a "recv = False" param to yield.
Were you using an old version of my proposal when you typed this?

> Instead I using the "to" parameter to determine whether of not a
> yield is a send or receive. Define yield's paramenters as follows:
>
> (value=None, to=None)
>
> When "to" is specified then the yield is a send; when to is
> None, the default, the yield is a receive. If it is desired
> to use a thread manager as a pool of server threads then a
> ThreadMgr.AnyThread() method can be used as the yield's "to"
> argument to allow a message to be sent to the next free
> thread in the pool, or a randomly chosen thread for a simulation.

I think using "to" should be independent of whether you recv or not.  Check
out the current proposal.

> I do not know about the empty yield case. Usually this is handled
> with a sleep(0) in other languages. Or the ThreadMgr prototype can
> have a special method for this case. It will not occur often.

Yield() is actually a common call in several OS's for exactly the purpose I
suggested.  A nice coincidence.

> Summing up, an OS thread declaration:
>
> def thread1(seconds):
>     defInit: thread1 = OSThread(thread1)
>     print("thread1 is running")
>     Sleep(seconds * 1.0)
>     print("thread1 is stopping")
>
> A prothon thread:
>
> def thread1(seconds):
>     defInit: thread1 = Thread(thread1)
>     print("thread1 is running")
>     Sleep(seconds * 1.0)
>     print("thread1 is stopping")

These match my latest proposal exactly.

> A generator:
>
> def genOdd(n):
>     defInit: genOdd = Thread(genOdd)
>     for i in n:
>         if i % 2:
>             yield(i)

In my latest proposal I brought back the gen keyword as syntax sugar for
this construct.

> Finally, this is how I defined a Tasklet generator class in Stackless
> Python along with an example usage. Note that special care was taken
> to handle the case where the generator function never does a yield:

That looks fine.

I think we are pretty much in agreement except for some small details.  You
provided almost all of this solution.  You did a very good job.  Many
thanks.

What did you think of the containment hierarchy idea?  Christian put his
stamp of approval on the limitation of one thread per ThreadMgr in private
email.  He said he will study the whole proposal soon and that he isn't mad
at me. :-)