On Sun, 2007-08-19 at 13:13 +0300, Rhythmic Fistman wrote:
> My driver itself cheats in this respect, using
> an schannel with some c code that reschedules every fthread
> hanging on an schannel, as though you executed a "read n times,
> discarding result". Um. So in conclusion, I think I'm close to
> a nice clean robust design for this kind of thing, but not quite.
> Any suggestions?
Generic comments first (others code is always hard to read :)
If you do this:
var chan = mk_schannel[int] ();
spawn_fthread{
var i : int;
for (i=0; i<10; ++i) {
write (chan,1);
}
};
spawn_fthread{
var i : int;
forever {read (&i,chan); println q"read $(i)"; };
};
the read fthread will hang, even when the first fthread has terminated.
Why? Because, someone else might write on chan. Because chan is
reachable = visible. But if you do this:
proc launcher() {
var chan = mk_schannel[int] ();
spawn_fthread{
var i : int;
for (i=0; i<10; ++i) {
write (chan,1);
}
};
spawn_fthread{
var i : int;
forever {read (&i,chan); println q"read $(i)"; };
};
}
launcher();
Then the second fthread will die after loses control after
the last read (i=9), but not before the first one dies ..
PROVIDED of course you call the collector!
So the point of this note is that you should carefully
restrict the visibility of any channels you create
to the fthreads that communicate using them: if any
active thread COULD use the channel, other threads
waiting on it will not die.
--
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
