This is starting to look reasonable I think.
Comments appreciated. Caveats etc after.
/// interface ////
interface future_t[T] {
doget: 1 -> T;
fetched: 1 -> bool;
fetch: 1 -> 0;
}
/// implementation ///
object future[T] (e:1->T) implements future_t[T] = {
var ch = mk_schannel[T]();
spawn_fthread { write (ch,#e); };
var x:T;
var flag = false;
method fun fetched() => flag;
method proc fetch() {
x = read ch;
flag = true;
}
method fun doget() => x;
};
/// syntax
inline gen get[T](fut:future_t[T]):T = {
if not #(fut.fetched) call fut.fetch;
return #(fut.doget);
}
// simple example
var x = future { 42 };
println$ x.get;
// More nasty example
var ch = mk_schannel[int]();
var y = future { var k = read ch; return k; };
spawn_fthread { write (ch, 77); };
println$ y.get;
/////
Now some notes.
Finally we have some schannel code where the use of the
schannel and fibre appears to be transparent. But there's
still a weakness here.
Schannels are garbage collected, so they can't be deleted until
they're unreachable. The future objects here know about the
schannel so it won't be deleted until the object is.
That is a weakness. It can be fixed by NULLing out the schannel,
except there's no code in the library to do that . Note that the a fibre
"deadlocked" on the schannel will suicide when the schannel is deleted.
Note that in the second example, the future or the spawn can be
done in either order, however the get must be done after the spawn,
or the get will lock up waiting for a write from a fibre that hasn't
been launched. In the example, that will cause the mainline
to suicide.
Ok, so the caveat here is that the get function MUST be inlined.
It cannot me a method of the future object because such methods
are always closures. A procedural closure would be just fine,
such as "fetch", since they can do service calls, but functional
closures cannot. So the get method has to be external to the object.
Provided we regard evaluating a future as having a side effect,
the usual caveats apply: you cannot use one in a function,
only in a procedure or generator. However you cannot use
one in a generator closure either: if you put one in a generator
it has to be inlined, and its container has to be inlined to,
until we inline all the way to a top level procedure.
So it's important to understand a future should be viewed as
both side-effecting and doing a service call.
To make usage more reliable more checking is needed
in the compiler: yields, service calls, recursion, inlining and
closure interact in predictable but somewhat ugly ways.
Semantically, a future is sort of a like a "val": the time of
evaluation is indeterminate. However unlike a lazily
evaluated computation at the moment, futures only
get evaluated at most once: a second get will just
use the cached value.
A future should be able to do async I/O too.
It should be able to read from a socket.
This will suspend the fibre at least until
data is available and may lock up the get.
However the BIG advantage is that the read is requested
and then the program can continue on doing other stuff,
so we just effected asynchronous I/O. Normally if you read
a socket, it will suspect the calling fthread: the I/O is
asynchronous an non-blocking with respect to the pthread
that starts it, but blocking and synchronous with respect
the fibre. Future allow you to do fibre-relative async I/O.
[Note: you cannot do partial reads or test if the read is
complete, you have to block. But you can delay the blocking]
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
