[erlang-questions] Futures/promises and ability to "call" abstract modules

[Vlad Dumitrescu]

I have no idea, that's why I asked :-)
/Vlad


On Mon, Nov 19, 2012 at 11:44 AM, Gleb Peregud <gleber.p@REDACTED> wrote:

> I assumed that NIF-generated resources are shared between processes (the
> same way as large binaries are), and I haven't done any tests on this. Are
> you sure it is garbate collected multiple times (once per referencing
> process)?
>
>
>
> On Mon, Nov 19, 2012 at 11:41 AM, Vlad Dumitrescu <vladdu55@REDACTED>wrote:
>
>> Hi Gleb,
>>
>> 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...
>>
>> regards,
>> Vlad
>>
>>
>> On Mon, Nov 19, 2012 at 11:32 AM, Gleb Peregud <gleber.p@REDACTED>wrote:
>>
>>> Hello
>>>
>>> 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).
>>>
>>> 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)?
>>>
>>> I've implemented futures using processes and message passing and
>>> stumbled upon two issues:
>>> 1) garbage collection of futures
>>> 2) slightly too much code when using them
>>>
>>> Example of the first problem is here:
>>>
>>> 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
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> The second issue is illustrated here:
>>>
>>> 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
>>>
>>> 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()".
>>>
>>> This can be done by extending concept of "abstract modules" with
>>> "default call". Currently abstract modules allow the following:
>>>
>>> {future, Pid, Ref, undefined}:get() which is translated to
>>> future:get({future, Pid, Ref, undefined})
>>>
>>> With a simple change in beam_emu.c in call_fun function (which would
>>> replace obsolete fun tuples) we can allow for the following:
>>>
>>> {future, Pid, Ref, undefined}() which COULD be translated to
>>> future:call({future, Pid, Ref, undefined})
>>>
>>> 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).
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Gleb Peregud
>>>
>>> 1: http://monkey.org/~marius/talks/twittersystems/
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121119/c4ce5b61/attachment.htm>