<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 20 nov 2012, at 16:20, Gleb Peregud <<a href="mailto:gleber.p@gmail.com">gleber.p@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">This is yet to be implemented. The idea is to rely on already existing<br>implementation of NIF resources - this implies that a user of the<br>library would have to always store Pid of garbage collectable process<br>(let's call it gcproc) along with that resource in his heap, for<br>example as {'gcproc', pid(), resource()} and use special API to do<br>sending, killing, linking, monitoring, etc.<br><br>Since the resource associated with the process is always stored in<br>heap of the process, the resource will not get garbage collected until<br>no heap references it. This way we tie together process and resource<br>lifetime. And since NIF resources can have a destructor in C which is<br>called upon resource is garbage collected, we can make use of it to<br>inform gcproc to terminate.<br><br>As Patrik pointed out it is not as trivial as it sounds, but still possible.<br><br></blockquote>Maybe <a href="git://github.com/tonyrog/resource.git">git://github.com/tonyrog/resource.git</a> could come in handy.</div><div><br></div><div>/Tony</div><div><br><blockquote type="cite">On Tue, Nov 20, 2012 at 3:34 PM, David Mercer <<a href="mailto:dmercer@gmail.com">dmercer@gmail.com</a>> wrote:<br><blockquote type="cite">How does that spawned process get garbage collected?<br><br>Cheers,<br><br>DBM<br><br><br><blockquote type="cite">-----Original Message-----<br>From: <a href="mailto:erlang-questions-bounces@erlang.org">erlang-questions-bounces@erlang.org</a> [mailto:erlang-questions-<br><a href="mailto:bounces@erlang.org">bounces@erlang.org</a>] On Behalf Of Dmitry Belyaev<br>Sent: Monday, November 19, 2012 21:48<br>To: Gleb Peregud<br>Cc: Erlang<br>Subject: Re: [erlang-questions] Futures/promises and ability to "call"<br>abstract modules<br><br>Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:2:2] [async-threads:0]<br>[hipe] [kernel-poll:false]<br><br>Eshell V5.9.1 (abort with ^G)<br>1> F = (fun() -> FM = fun(M, V) -> receive {value, Value} -> M(M, Value);<br>{get, P} -> P ! V, M(M, V) end end, P = spawn(fun() -> FM(FM, undefined)<br>end), fun() -> P ! {get, self()}, receive V -> V end end end)().<br>#Fun<erl_eval.20.82930912><br>2> F().<br>undefined<br>3> element(2,lists:keyfind('P', 1,<br>lists:flatten(element(2,erlang:fun_info(F, env))))) ! {value, 10}.<br>{value,10}<br>4> F().<br>10<br>5><br><br>--<br>Dmitry Belyaev<br><br>On 19.11.2012, at 18:05, Gleb Peregud wrote:<br><br><blockquote type="cite">Then I wouldn't be able to set future's value after it being defined.<br>Like in this example:<br><br>7> F = future:new().<br>{future,<0.47.0>,#Ref<0.0.0.27235>,undefined}<br>8> spawn(fun() -> timer:sleep(10000), F:set(42) end).<br><0.49.0><br>9> F:get().<br>42<br><br>Without this ability such futures are useless with request-reply<br></blockquote>pattern:<br><blockquote type="cite">1) Client sends request<br>2) Server creates a future and sends it back to client<br>3) Client does it's work with the value of the future (without<br>bothering the fact that value may become available in uncertain<br>future)<br>4) Server finishes computations and sets future's value<br><br><br>On Mon, Nov 19, 2012 at 3:01 PM, Robert Virding<br><<a href="mailto:robert.virding@erlang-solutions.com">robert.virding@erlang-solutions.com</a>> wrote:<br><blockquote type="cite">Wouldn't it be easier if future:new just returned a fun? Then you could<br></blockquote></blockquote>do F() without any changes?<br><blockquote type="cite"><blockquote type="cite"><br>Robert<br><br>----- Original Message -----<br><blockquote type="cite">From: "Gleb Peregud" <<a href="mailto:gleber.p@gmail.com">gleber.p@gmail.com</a>><br>To: "Vlad Dumitrescu" <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>><br>Cc: "Erlang" <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>Sent: Monday, 19 November, 2012 2:18:11 PM<br>Subject: Re: [erlang-questions] Futures/promises and ability to<br>"call" abstract modules<br><br>With the these changes [1] the following code works as intended:<br><br>7> F = future:new(fun() -> timer:sleep(5000), 42 end).<br>{future,<0.44.0>,#Ref<0.0.0.71>,undefined}<br>8> F().<br>42<br><br>Aside from a problem where it improperly reports arity in case of<br>undefined function:<br><br>9> F(1,2,3).<br>** exception error: undefined function future:call/3<br><br>1: <a href="https://github.com/gleber/otp/compare/call-abstract-module">https://github.com/gleber/otp/compare/call-abstract-module</a><br><br>On Mon, Nov 19, 2012 at 11:48 AM, Gleb Peregud <<a href="mailto:gleber.p@gmail.com">gleber.p@gmail.com</a>><br>wrote:<br><blockquote type="cite">Sverker Eriksson wrote the following in [1]:<br><br><blockquote type="cite">But even if the resource terms look alike, they are unique and<br>there is no bug leaking NIF resources (that I know of). A resource<br>is released (and destructor called) when the last reference is<br>garbage collected.<br>The shell can fool you however, as it keeps a command history that<br>can retain terms even though you think the variables are<br>forgotten.<br>Test NIF<br>resource cleanup by running a test module and call<br>erlang:garbage_collect to force destructors to be called.<br></blockquote><br>This seems to mean that they are "shared" and garbage collected<br>just once.<br><br>1:<br><a href="http://erlang.org/pipermail/erlang-questions/2011-January/055524.ht">http://erlang.org/pipermail/erlang-questions/2011-January/055524.ht</a><br>ml<br><br>On Mon, Nov 19, 2012 at 11:46 AM, Vlad Dumitrescu<br><vladdu55@gmail.com> wrote:<br><blockquote type="cite">I have no idea, that's why I asked :-) /Vlad<br><br><br>On Mon, Nov 19, 2012 at 11:44 AM, Gleb Peregud<br><gleber.p@gmail.com> wrote:<br><blockquote type="cite"><br>I assumed that NIF-generated resources are shared between<br>processes (the same way as large binaries are), and I haven't<br>done any tests on this. Are you sure it is garbate collected<br>multiple times (once per referencing process)?<br><br><br><br>On Mon, Nov 19, 2012 at 11:41 AM, Vlad Dumitrescu<br><vladdu55@gmail.com><br>wrote:<br><blockquote type="cite"><br>Hi Gleb,<br><br>just a quick observation about garbage collecting futures: would<br>the NIF-generated resource keep track of usage across processes?<br>I fI send a future as a message, it may be referenced by<br>multiple processes which have their own heap and garbage<br>collection...<br><br>regards,<br>Vlad<br><br><br>On Mon, Nov 19, 2012 at 11:32 AM, Gleb Peregud<br><gleber.p@gmail.com><br>wrote:<br><blockquote type="cite"><br>Hello<br><br>Last evening I was trying to implement futures/promise<br>mechanism in Erlang (mostly for fun, since I am still unsure if<br>it is useful). I got inspired with the presentation [1], which<br>mentioned using futures as a foundation of building services,<br>where things like timeouts, tracing, authentication, etc. is<br>built by composing futures (see slide 41).<br><br>Do you think that such composition of futures could be useful<br>as a tool to improve code reuse of communication patterns in<br>Erlang (as described in the presentation)?<br><br>I've implemented futures using processes and message passing<br>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><br>1> F = future:new(fun() -> timer:sleep(10000), 10 end).<br>{future,<0.36.0>,#Ref<0.0.0.1736>,undefined}<br>2> F:get(). %% it hangs for 10 seconds<br>10<br><br>Since future F is represented as a process <0.36.0> it will<br>stay running forever till it's timed out (which is not a good<br>solution, since someone may still have a reference to this<br>future) or F:done() manually called.<br><br>My idea is to insert into 'future' tuple a NIF-generated<br>resource, which will have a destructor attached (called upon<br>garbage collection of the<br>resource) which will call F:done(). Will it work?<br><br>The second issue is illustrated here:<br><br>7> F = future:new().<br>{future,<0.47.0>,#Ref<0.0.0.27235>,undefined}<br>8> spawn(fun() -> timer:sleep(10000), F:set(42) end).<br><0.49.0><br>9> F:get().<br>42<br><br>In ideal world it should be enough to just write "F" (without<br>:get()) to<br>fetch future's value, but it seems too far fetched for Erlang.<br>Slightly<br>better solution would be to allow calling future with "F()".<br><br>This can be done by extending concept of "abstract modules"<br>with<br>"default call". Currently abstract modules allow the following:<br><br>{future, Pid, Ref, undefined}:get() which is translated to<br>future:get({future, Pid, Ref, undefined})<br><br>With a simple change in beam_emu.c in call_fun function (which<br>would replace obsolete fun tuples) we can allow for the<br>following:<br><br>{future, Pid, Ref, undefined}() which COULD be translated to<br>future:call({future, Pid, Ref, undefined})<br><br>hence allowing to use just "F()" to read a value of the future.<br>This<br>will also extend "metaprogramming" capabilities of Erlang for<br>some other quirky use, which may or may not be a Good<br>Thing(tm).<br><br>Thoughts?<br><br>Cheers,<br>Gleb Peregud<br><br>1: http://monkey.org/~marius/talks/twittersystems/<br><br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br><br></blockquote><br></blockquote><br></blockquote><br></blockquote></blockquote>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br><br></blockquote></blockquote>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote><br></blockquote>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; ">"Installing applications can lead to corruption over time. </span><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; ">Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; "><br></span></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>