Re: Re: stackless language features

Lenard Lindstrom <[email protected]> Fri, 2 Jul 2004 15:58:17 -0700 (Pacific Daylight Time)

Newsgroups	gmane.comp.lang.prothon.user
Message-ID	<Mahogany-0.66.0-4294595635-20040702-163247.00@pop3.norton.antivirus>

On Tue, 29 Jun 2004 12:22:51 -0700 Mark Hahn <[email protected]> wrote:

> Lenard Lindstrom wrote:
> 
> > thread <name> (arg, ...):
> >     <body>
> 
> I like this for replacing the OS thread statement and specifying the new
> soft threads.  I hated the params argument in the old OS hard thread
> constructor.  I'm not sure how we can specify what type of thread we are
> making though.  Maybe we can have two different keywords.
> 
> > In this case thread just replaces the gen keyword.
> 
> Cool idea.  You've accomplished what you said you wanted to do about merging
> gen and threads.  I will give some thought to see if there is any problem
> with such a simple idea.
> 
> How about an OSThread (osThread?) keyword and a thread keyword.  It would be
> weird to have a camelcase keyword but I cannot think of any other.
>
I was thinking of an earlier proposal where a new OS level thread was created
if a current thread what not specified:

thread foo ...
    ...

os_thd = foo.thread()               # No argument to thread(), new OS thread
tasklet = foo.thread(os_thread_id)  # New mini thread for an existing OS thread

> I've been thinking lately about the name for the gate (my old name) aka
> channel (Christian's name).  Christian pointed out the ideal-meaning but
> impractical name rendezvous.  I would like to suggest "coupler" since this
> is an object that maintains a queue of threads waiting for a mate to be
> coupled with and then it pairs them off.  You can thank my wife for this
> obscene idea. :-)
> 
> I think the coupler should just be constructed with a normal call_ and
> init_.  Any fine-tuning of the scheduling would be done by setting
> attributes of the coupler.
> 
Sure. If there were some way to tie this "coupler" into a generator then
the "yield" keyword can go away. Maybe creating a generator instance
causes a "yield" coupler object to be created that is accessed through
the call stack:

thread fib(n):
    sum, prev = 1, 0
    for i in n:
        caller.yield.send(sum)
        sum, prev = sum + prev, sum

Lenard Lindstrom
<[email protected]>