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

[Gleb Peregud]

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/8ba19d57/attachment.htm>