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

[Patrik Nyblom]

On 11/19/2012 11:48 AM, Gleb Peregud wrote:
> Sverker Eriksson wrote the following in [1]:
>
>> But even if the resource terms look alike, they are unique and there is
>> no bug leaking NIF resources (that I know of). A resource is released
>> (and destructor called) when the last reference is garbage collected.
>> The shell can fool you however, as it keeps a command history that can
>> retain terms even though you think the variables are forgotten. Test NIF
>> resource cleanup by running a test module and call
>> erlang:garbage_collect to force destructors to be called.
> This seems to mean that they are "shared" and garbage collected just once.
That is correct. The callback however, is not really able to send 
messages, you would have to relay information to a thread which in turn 
would have to send a message to the future to make it exit. It seems to 
be technically possible at least, given an SMP VM. You would more or 
less implement garbage collection of processes, which would be kind of 
cool, I think :)

Of course distribution would generate a slightly bigger challenge...

Cheers,
/Patrik
>
> 1: http://erlang.org/pipermail/erlang-questions/2011-January/055524.html
>
> On Mon, Nov 19, 2012 at 11:46 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
>> 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
>>>>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions