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