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

[Gleb Peregud]

Thanks for info :) Distributed version, if implemented nicely, would
probably need changes in ERTS (e.g. ability to send resources between
nodes and call some callbacks upon receive); otherwise users of
library would need to manually call something like F:register() upon
every receive...

Actually garbage collection of processes may be useful as a standalone
library - I had few situations when I wanted it to exist (but always
managed to do the job without it).

On Mon, Nov 19, 2012 at 2:38 PM, Patrik Nyblom <pan@REDACTED> wrote:
> 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
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions