Hi Gleb,<div><br></div><div>just a quick observation about garbage collecting futures: would the NIF-generated resource keep track of usage across processes? I fI send a future as a message, it may be referenced by multiple processes which have their own heap and garbage collection...</div>

<div><br></div><div>regards,</div><div>Vlad</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 11:32 AM, Gleb Peregud <span dir="ltr"><<a href="mailto:gleber.p@gmail.com" target="_blank">gleber.p@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello<br><br>Last evening I was trying to implement futures/promise mechanism in Erlang (mostly for fun, since I am still unsure if it is useful). I got inspired with the presentation [1], which mentioned using futures as a foundation of building services, where things like timeouts, tracing, authentication, etc. is built by composing futures (see slide 41).<br>



<br>Do you think that such composition of futures could be useful as a tool to improve code reuse of communication patterns in Erlang (as described in the presentation)?<br><br>I've implemented futures using processes and message passing and stumbled upon two issues:<br>



1) garbage collection of futures<br>2) slightly too much code when using them<br><br>Example of the first problem is here:<br><pre><code>1> F = future:new(fun() -> timer:sleep(10000), 10 end).
{future,<0.36.0>,#Ref<0.0.0.1736>,undefined}
2> F:get(). %% it hangs for 10 seconds
10</code></pre>Since future F is represented as a process <0.36.0> it will stay running forever till it's timed out (which is not a good solution, since someone may still have a reference to this future) or F:done() manually called.<br>



<br>My idea is to insert into 'future' tuple a NIF-generated resource, which will have a destructor attached (called upon garbage collection of the resource) which will call F:done(). Will it work?<br><br>The second issue is illustrated here:<br>



<pre><code>7> F = future:new().                                      
{future,<0.47.0>,#Ref<0.0.0.27235>,undefined}
8> spawn(fun() -> timer:sleep(10000), F:set(42) end).
<0.49.0>
9> F:get().
42</code></pre>In ideal world it should be enough to just write "F" (without :get()) to fetch future's value, but it seems too far fetched for Erlang. Slightly better solution would be to allow calling future with "F()".<br>



<br>This can be done by extending concept of "abstract modules" with "default call". Currently abstract modules allow the following:<br><br>{future, Pid, Ref, undefined}:get() which is translated to future:get({future, Pid, Ref, undefined})<br>



<br>With a simple change in beam_emu.c in call_fun function (which would replace obsolete fun tuples) we can allow for the following:<br><br>{future, Pid, Ref, undefined}() which COULD be translated to future:call({future, Pid, Ref, undefined})<br>



<br>hence allowing to use just "F()" to read a value of the future. This will also extend "metaprogramming" capabilities of Erlang for some other quirky use, which may or may not be a Good Thing(tm).<br>



<br>Thoughts?<br><br>Cheers,<br>Gleb Peregud<br><br>1: <a href="http://monkey.org/~marius/talks/twittersystems/" target="_blank">http://monkey.org/~marius/talks/twittersystems/</a> <br>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>