On Tue, 2007-08-21 at 16:38 +0300, Rhythmic Fistman wrote:
> On 8/19/07, skaller <[EMAIL PROTECTED]> wrote:

> called timing fns. No, my problem here turned out to be a form
> of starvation: the flx runtime when executing a read or write
> always reschedules an fthread, however  instead of that thread
> going to the end of the active queue, like a good englishman,
> it jumps straight to the front, all'italiana.  This means that
> if you have two fthreads writing to one schannel with a third
> fthread reading from it, the second writing fthread will not be
> rescheduled until the first writer exits, if it exits. 

That's possible ..

> I'm not
> sure that this behaviour is 100% wrong: fthread scheduling is
> blissfully undefined

Indeterminate, yes. Actually there is one change I think could
be made: when a read/writer synchronise, the last active one
continues on. What probably should happen is that the reader
is *always* scheduled next. The reason is: so it can copy
data from the writer, in particular the writers stack.

>  and probably should be that way, also all
> fthreads  will have forward progress if they terminate, and
> the code's probably more instruction cache friendly, but on the
> other hand, it doesn't feel right either. 

It's right: fthreads are not supposed to be fair, it's not supposed
to matter. If it matters, you should probably forcing the ordering
*in* your application using schannels.

However, the scheduler could be made plugable, even have priorities
or something. Just need an abstraction like:

        class scheduler {
                virtual void enqueue_thread(fthread_t*)=0;
                virtual fthread_t *dequeue_fthread()=0;
        };



> I DO want to write
> non-terminating flx procedures that communicate/deschedule themselves
> via schannels,  that just evaporate  when the other end of
> the schannel goes away:
> 
> proc gen_coords(ch: schannel[point]) {
>   forever {
>     write_chan(ch, gen_pt(t));
>   };
> }

Yes, that's a tick generator.. :)

> The above mightn't be the best example, it would more simply
> done with a generator (does felix have generators? what's the
> syntax?)

Felix has generators: functions with a 'yield' statement.
Yield returns, after saving the resume address (same as
procedures), and re-entry jumps to that location (same
as procedures). The difference is generators return a value,
whereas procedures return the current continuation.

So to resume a generator, you have to store it in a variable.
Unlike functions, generators do not clone themselves when called.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to